Catégorie : agile

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

Comment manager la dette technique sans tout bloquer ?

Le par mopertodans agileLaisser un commentaire

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.

Le par mopertodans agileLaisser un commentaire

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 ?

Le par mopertodans agileLaisser un commentaire

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)

Le par mopertodans agileLaisser un commentaire

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

Le par mopertodans agileLaisser un commentaire

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.

Le par mopertodans agileLaisser un commentaire

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®)

Le par mopertodans agile, formations et certifications1 commentaire

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

Le par mopertodans agile, leadershipLaisser un commentaire

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 ?

Le par mopertodans agile, formations et certificationsLaisser un commentaire

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 par mopertodans agile, experience sharingLaisser un commentaire

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

Le par mopertodans agileLaisser un commentaire

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 !

Le par mopertodans agile, best practicesLaisser un commentaire

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

L’organisation adaptative – 7 actions transformatrices dans le management de projet.

Le par mopertodans agile, pmo et portofolioLaisser un commentaire

À l’aide des conseils de ce livre blanc, vous découvrirez 7 actions transformatrices de management de projet  pour une organisation adaptative.

The Adaptive Organization – 7 Transformative Project Management Actions

https://www.pmsolutions.com/resources/view/the-adaptive-organization-seven-transformative-project-management-actions/

Les temps changent et les organisations doivent se préparer dès maintenant et en permanence à répondre avec agilité à tout ce qui pourrait arriver.

Qu’est-ce que l’Agilité Organisationnelle ?

Téléchargez le livre blanc.

Ce concept qui fut à la mode dans le passé, a été reconnu comme une capacité business essentielle pendant la pandémie et les perturbations économiques qui ont suivi, et il son urgence s’ est accrue en 2023 avec la montée en puissance de l’IA.

Votre organisation doit être capable de s’adapter à des circonstances qui évoluent et changent rapidement. Vous devez rester à l’affût des risques et des opportunités, manager vos équipes distribuées et vous appuyer sur une main-d’œuvre collaborative auto-managée.

À l’aide des conseils de ce livre blanc, vous découvrirez 7 actions de management de projet transformatrices pour une organisation adaptative.

  1. Privilégiez les bénéfices.
  2. Mettez en place un PMO agile.
  3. Mesurez la maturité et les progrès.
  4. Formez-vous pour l’état d’esprit, pas pour la conformité.
  5. Choisissez la bonne approche.
  6. Suivez des principes, pas des procédures.
  7. Faites confiance à vos équipes.

 

Connaissez-vous le Glossaire Agile ?

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

The Agile Glossary by the Agile Alliance.

https://www.agilealliance.org/agile101/agile-glossary/

Apprenez la terminologie unique utilisée dans le développement Agile auprès des experts d’Agile Alliance.

Si vous avez des suggestions de révisions à apporter à des termes existants ou des idées pour de nouveaux termes, n’hésitez pas à les en informer.

Chaque terme est expliqué en détail avec des exemples, ses pièges, ses origines…

Visitez le site

Voici quelques exemples que j’ai trouvés intéressants

Heartbeat Retrospective – Rétrospective des battements de cœur

L’équipe se réunit régulièrement pour réfléchir aux événements les plus importants survenus depuis la dernière réunion et identifier les possibilités d’amélioration.

Information Radiators – Radiateurs d’Informations

Le terme « radiateur d’information » désigne l’un des nombreux affichages visuels qu’une équipe place dans un endroit très visible, de sorte que tous les membres de l’équipe peuvent voir les dernières informations en un coup d’œil.

Minimum Marketable Feature (MMF) – Fonctionnalité  minimale commercialisable/utilisable

Une fonctionnalité minimale commercialisable est une petite fonctionnalité autonome qui peut être développée rapidement et qui offre une valeur significative à l’utilisateur.

Rules of Simplicity – Règles de simplicité

« Rules of Simplicity » est un ensemble de critères, par ordre de priorité, proposés par Kent Beck pour juger si un code source est « assez simple ».

CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM

SPIDR : 5 façons simples mais puissantes de découper les histoires utilisateur / user stories

Le par mopertodans agile, best practicesLaisser un commentaire

Presque toutes les histoires peuvent être divisées avec l’une des 5 techniques suivantes. Apprenez ces cinq approches simples et vous serez prêts.

SPIDR: Five Simple but Powerful Ways to Split User Stories par Mike Cohn

https://www.mountaingoatsoftware.com/blog/five-simple-but-powerful-ways-to-split-user-stories

L’une des difficultés les plus courantes rencontrées par les équipes agiles est la nécessité de découper des histoires utilisateur. Je suis sûr que vous avez aussi eu du mal avec cela. C’est certainement ce que m’est arrivé au début.

En fait, quand j’ai commencé à utiliser Scrum, dans certains de nos arriérés de produit, les histoires étaient si grosses que nous avons parfois opté pour des sprints de six semaines. Avec un peu plus d’expérience, cependant, cette équipe et moi avons vu suffisamment de façons de décomposer le travail pour que nous puissions faire des sprints d’une journée si nous l’avions voulu.

Mais décomposer les histoires a été difficile au début. Vraiment dur.

J’ai de bonnes nouvelles pour vous. Non seulement j’ai compris comment découper des histoires par moi-même, mais j’ai aussi appris à expliquer comment le faire afin que tout le monde puisse rapidement devenir un expert. (Si vous voulez jeter un coup d’œil dans les coulisses de vraies histoires d’utilisateurs de certains de mes premiers backlogs de produits, avec des commentaires sur ce que je ferais différemment aujourd’hui : Télécharger 200+ exemples de User Story).

Ce que j’ai découvert, c’est que presque toutes les histoires peuvent être divisées avec l’une des cinq techniques suivantes. Apprenez ces cinq techniques simples et vous êtes prêt.

Mieux encore, les cinq techniques forment un acronyme facilement mémorisable : SPIDR.

Je présente chaque technique ci-dessous, et cette vidéo les montre en action.

Technique SPIDR pour diviser les histoires

Il y a quelques années, je créais le cours « Better User Stories ». Parce que ce cours couvrirait tout ce que quelqu’un doit savoir pour travailler efficacement avec des histoires, je savais qu’il fallait d’un module sur le fractionnement.

Pour créer ce module, j’ai imprimé plus d’un millier d’histoires ‘utilisateur que j’avais rassemblées pendant 15 ans. Pour chaque histoire, j’avais l’histoire originale et les sous-histoires dans lesquelles elle avait été divisée. J’ai collé chaque histoire sur le mur, en les regroupant en fonction de la façon dont elles avaient été divisées. Je cherchais les approches communes utilisées pour découper toutes ces histoires. Je suis passé par une variété de regroupements, en essayant de trouver le plus petit ensemble d’approches possible. Je savais qu’il serait plus facile de se souvenir de 5 techniques de fractionnement plutôt que de 20.

Les cinq que j’ai obtenues forment l’acronyme SPIDR : S, P, I, D et R (spider sans E).

Jetons un coup d’œil aux cinq techniques de fractionnement des user stories qui composent l’acronyme SPIDR, avec des exemples de la façon dont votre équipe pourrait les utiliser.

#1 – Diviser les User Stories à l’aide d’un Spike

S comme Spike. C’est un problème que la plupart des équipes agiles connaissent. Un spike est une activité de recherche qu’une équipe entreprend pour en savoir plus sur un élément de l’arriéré. Les spikes peuvent également donner aux équipes les connaissances dont elles ont besoin pour diviser une histoire complexe. Considérez-le comme une activité de recherche, mais il peut inclure du prototypage ou du codage expérimental.

Au cours d’un spike, une équipe n’essaie pas de développer la nouvelle fonctionnalité, mais plutôt de développer de nouvelles connaissances qui l’aideront à développer la fonctionnalité plus tard.

Prenez YouTube par exemple. Remontez dans le temps, à l’époque où YouTube ajoutait le sous-titrage automatique. L’équipe qui s’est chargée de cela aurait peut-être été confrontée à une décision de construction ou d’achat. Utilisent-ils un logiciel disponible dans le commerce pour générer les sous-titres ? Ou leurs besoins sont-ils si uniques qu’ils doivent développer quelque chose à partir de zéro ? La façon de régler cela serait un spike pour tester un ou plusieurs produits de sous-titrage disponibles dans le commerce.

L’extraction d’un spike réduit la taille de l’article d’origine, car une partie ou la totalité des recherches incluses dans l’article d’origine est supprimée. C’est absolument un moyen essentiel de diviser les histoires. L’extraction d’un spike est donc l’une des cinq techniques de fractionnement que vous devriez utiliser. Mais normalement, ce ne sera pas la première technique que vous utiliserez.

#2 – Diviser les User Stories par Path (chemin)

P comme Path. Si un utilisateur peut faire quelque chose de plusieurs façons (par exemple, payer avec une carte ou Apple Pay), c’est un excellent domaine pour diviser.

Pour diviser une histoire en chemins, recherchez d’autres chemins d’accès à travers l’histoire.

Pour rester sur YouTube, utilisons l’histoire : « Je peux partager une vidéo avec mes amis ».

Lorsque je clique sur le bouton « Partager » sur YouTube aujourd’hui, on me montre 14 boutons sur lesquels je peux cliquer pour partager directement sur divers réseaux sociaux. On me montre également un lien que je peux copier. Et j’ai la possibilité de personnaliser ce lien pour démarrer la lecture de la vidéo partagée à un moment précis de la vidéo.

Il s’agit de 16 chemins différents à travers l’histoire « Je peux partager une vidéo ». Je ne sais pas si cette histoire a besoin d’être divisée en autant de sous-histoires plus petites. C’est à l’équipe de décider en fonction de l’effort impliqué. Mais, avec la seule technique du chemin, nous avons identifié 16 chemins à travers l’histoire originale.

#3 – Diviser les User Stories par Interfaces

I est pour Interfaces : Diviser votre histoire par navigateur ou matériel, ou fournir une interface complexe par itérations. Par exemple, vous pouvez proposer une version qui ne fonctionne que dans Chrome dans cette itération et prévoir Safari pour une autre itération.

Dans d’autres cas, le découpage par interface signifie la création d’une version simple de l’interface et d’une version plus complexe en tant qu’histoires distinctes. Cela s’applique généralement à l’interface utilisateur.

En appliquant cela à notre exemple de partage de vidéos YouTube, au lieu de diviser cette histoire par des chemins, nous aurions pu séparer une histoire de partage de base telle que : « En tant que spectateur de vidéos, je peux obtenir une URL que je peux partager ». Cela pourrait être mis en œuvre sans autre interface utilisateur qu’un bouton de partage sur la page vidéo. La fenêtre contextuelle avec les 16 différentes façons de partager ne serait pas nécessaire si la seule façon de partager est avec une URL.

Une histoire ultérieure pourrait être : « En tant que spectateur, je peux partager une vidéo sur divers sites de médias sociaux. » Cela pourrait être fait avec une interface utilisateur très simple au début – pas de fantaisie de faire défiler une liste de logos, peut-être juste une liste déroulante de texte avec les noms des sites sociaux.

L’histoire finale pourrait alors ressembler à quelque chose comme : « En tant que spectateur, je peux choisir le réseau social sur lequel partager en faisant défiler une liste montrant les logos de chacun. »

La division par interface fonctionne parce que la fonctionnalité finalement souhaitée peut être atteinte par des interfaces de plus en plus détaillées et meilleures.

#4 – Diviser les User Stories par Data / Données

Le D de l’acronyme SPIDR signifie Données.  Pour diviser une histoire par données, demandez-vous si vous pouvez apporter de la valeur dans une itération en simplifiant ou en limitant les données prises en charge. Peut-être pouvez-vous faire une version initiale d’une histoire qui ne traite qu’un sous-ensemble des données qui devront finalement être prises en charge. Par exemple, n’autorisez pas les soldes bancaires négatifs dans la première itération. Ajoutez la prise en charge de ceux avec une histoire utilisateur différente dans la prochaine itération.

Pour revenir à l’exemple de YouTube, YouTube vous permet de télécharger une vidéo dans l’un des 16 formats de fichiers différents. Si nous construisons un concurrent de YouTube, oublions les 16 formats de fichiers. Commençons par 1. Nous allons prendre en charge un type de données. Pour l’instant, tous les téléchargements doivent être au format MP4. Nous ajouterons tous les autres plus tard en tant qu’histoires distinctes.

Le fractionnement par données est une approche efficace. Souvent, il y a quelques types de données qui ajoutent beaucoup de complexité. Eh bien, faites une mise en œuvre initiale qui ignore les données les plus complexes. Faites en sorte que cela fonctionne, puis ajoutez la prise en charge des données plus complexes. Vous ne pouvez probablement pas mettre en production la version la plus simple, mais vous pouvez toujours la construire dans cet ordre.

J’ai travaillé sur un système de ressources humaines qui faisait exactement cela. Le système suivait qui était le manager pour chaque employé et faisait des choses comme acheminer les demandes de congé à ce manager. La plupart des employés ont un manager, mais certains employés en ont plusieurs. Nous devions supporter le fait d’avoir plusieurs managers, mais certaines histoires ont été simplifiées au départ en supposant que chaque employé avait uniquement un manager.

#5 – Diviser les User Stories par des Règles / Rules

R comme Règles. Le relâchement temporaire de l’implémentation de règles qu’un article devra au final prendre en charge peut réduire la taille des grandes histoires.

Si l’on s’en tient à YouTube, par exemple, YouTube a des règles strictes concernant l’inclusion de musique protégée par des droits d’auteur dans les vidéos. Si nous construisons un concurrent à YouTube, la première histoire de notre équipe sera : « Je peux télécharger une vidéo pour que d’autres puissent la regarder. » Cette histoire semble probablement simple, mais il y a déjà beaucoup de choses à faire.

Donc, dans la première itération, ignorons la règle selon laquelle les vidéos ne peuvent pas contenir de musique protégée par des droits d’auteur. De toute façon, nous n’annonçons pas notre nouveau concurrent à YouTube au monde après une seule itération. Nous aurons tout le temps après ce premier sprint de nous conformer à notre règle interne interdisant les vidéos contenant de la musique protégée par des droits d’auteur.

Comme cet autre exemple lié à YouTube, supposons que nous voulions empêcher certains textes d’apparaître dans les commentaires. Il peut s’agir de jurons ou de commandes SQL qui peuvent être des tentatives de piratage. Bonne idée : Protégeons nos utilisateurs et notre système de ce type de texte dans les commentaires. Mais une première histoire du type « En tant qu’utilisateur, je peux entrer un commentaire sur une vidéo » peut ignorer cette règle. Cela rend l’histoire plus petite afin qu’elle puisse s’intégrer dans une itération. Et la prise en charge de la règle peut être ajoutée quelques itérations plus tard.

S’améliorer dans le fractionnement des histoires

S’améliorer dans le découpage des histoires d’utilisateurs est une compétence importante. Avec les courtes itérations utilisées en agile, il est utile d’avoir de petites unités de travail. Les cinq techniques que nous avons abordées ici (fractionnement par Spikes, Paths, Interfaces, Données et Règles) devraient vous permettre de fractionner n’importe quelle histoire.

Les techniques SPIDR sont faciles à retenir, mais leur mise en pratique peut nécessiter un peu d’entraînement et beaucoup de pratique. C’est pourquoi j’ai mis en place un cours vidéo « Better User Stories » qui inclut la méthode SPIDR pour diviser les histoires, et bien plus encore.

CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM

Utilisez les techniques de changement #Agile pour travailler plus intelligemment, pas plus dur.

Le par mopertodans agile, leadershipLaisser un commentaire

Dans un récent webinaire, Melanie Franklin a offert une mini-session de formation sur les techniques pour travailler plus intelligemment plutôt que plus dur. L’objectif est de vous aider à faire face à votre écrasante charge de travail.

Using Agile Change techniques to work smarter, not harder par Melanie Franklin

https://agilechangemanagement.co.uk/using-agile-change-techniques-to-work-smarter-not-harder/

Nous sommes tous tellement occupés, sous tellement de pression pour faire avancer les choses. Nous avons besoin de techniques qui nous aident à utiliser le moins d’énergie possible pour obtenir le meilleur retour sur nos efforts.

Les meilleures techniques pour travailler plus intelligemment, pas plus dur

Voici le résumé des techniques pour travailler plus intelligemment, pas plus dur.

Travaillez en courtes salves

  • Fragmentez le travail : Décomposez les tâches en petits morceaux gérables pour réduire la surcharge et augmenter la concentration.
  • Adoptez une approche itérative : Décomposez le travail en itérations ou en incréments pour le rendre gérable et maintenir le focus.

Utilisez des outils visuels

  • Représentez visuellement : Utilisez des visuels pour réduire la charge cognitive et faciliter le traitement de l’information.
  • Priorisez avec Kanban : Utilisez des tableaux visuels pour suivre les tâches et la progression (par exemple, À faire, En cours, Terminé).
  • Structurez une feuille de route : Créez d’une feuille de route pour visualiser et planifier le voyage, en apportant certitude et une approche étape par étape.

Utilisez les neurosciences pour travailler d’une manière respectueuse du cerveau

  • Comprenez les états cérébraux : Reconnaissez comment le cerveau réagit au stress (état de menace) et aux stimuli positifs (état de récompense) pour optimiser les performances.
  • Créez des émotions positives : Utilisez des techniques pour déclencher des substances chimiques positives du cerveau comme la dopamine (réalisations), les endorphines (substances chimiques de bien-être) et l’ocytocine (confiance et liaison).

Reconnaissez les réalisations

  • Recherchez les bénéfices : Concentrez-vous sur les tâches les plus précieuses et réfléchissez régulièrement aux progrès pour maintenir la motivation et la direction.
  • Célébrez et réfléchissez : Prenez le temps de célébrer les réalisations et de réfléchir à ce qui a été appris pour renforcer les expériences positives et l’amélioration continue.

Définissez vos critères de qualité et d’acceptation

  • Définissez les critères de réussite : Posez des critères de qualité et d’acceptation clairs dès le départ pour vous assurer que le travail répond aux normes requises et minimise le besoin d’être retravaillé

Gérez la charge de travail

  • Établissez des structures et des modèles reproductibles pour aider le cerveau à reconnaître et à anticiper les prochaines étapes.
  • Implémentez des techniques de hiérarchisation : Utilisez des méthodes comme Moscow (Must have, Should have, Could have, Won’t have) pour hiérarchiser les tâches en fonction de leur valeur et de leur urgence.
  • Capturez les idées : Notez rapidement vos idées pour éviter l’encombrement mental et rester concentré sur les tâches en cours.

Il est important de vous concentrer sur des techniques qui vous aideront à travailler plus intelligemment, et pas plus dur.

Ces techniques vous permettent de tirer parti des méthodologies agiles et des dernières idées des neurosciences et de la psychologie positive pour augmenter votre efficacité au travail. Ces techniques renforcent votre résilience au changement, et vous pouvez les utiliser pour gérer votre propre charge de travail et aussi pour aider vos collègues et les membres de votre équipe.

13 pratiques qui fonctionnent pour une transformation Agile

Le par mopertodans agile, pmo et portofolioLaisser un commentaire

Le PMO adaptatif, une tendance qui monte.

En 2018, The Adaptive Organization : A Benchmark of Changing Approaches to Project Management a identifié un certain nombre de bonnes pratiques pour les PMOs dans les organisations qui s’efforcent d’adopter des approches adaptatives et agiles pour les projets, les programmes et les portefeuilles.

En 2020, notre recherche sur l’état du management de projet a montré que les PMOs des organisations les plus performantes avaient adopté ces pratiques, obtenant de meilleurs résultats dans tous les domaines.

Avance rapide jusqu’en 2024 : Une nouvelle version de l’étude nous a permis d’établir une tendance dans la capacité des PMOs sur chaque pratique… ainsi qu’une nouvelle pratique qui montre la popularité croissante du management de projet en tant que service (PMaaS).

Les 13 meilleures pratiques des PMOs

  1. Choisir l’approche de management de projet (prédictive, adaptative ou hybride) la plus appropriée pour livrer le produit, le service ou le résultat.
  2. Conseiller la direction sur la valeur commerciale des projets qui utilisent des approches adaptatives.
  3. S’efforcer de fournir ce dont on a besoin et de prendre le pouls des clients.
  4. Fonctionner comme s’il s’agissait d’une entreprise de conseil, adaptant ses efforts pour répondre à des besoins spécifiques.
  5. Attendre que ses clients (clients, équipes) sollicitent ses services plutôt que de forcer des approches.
  6. Fournir des outils et des modèles adaptatifs.
  7. Fournir des cours de formation adaptés, des coachs ou des mentors.
  8. Coordonner les cours de formation adaptative, les coachs ou les mentors.
  9. Coordonner la communication entre les équipes qui utilisent des approches adaptatives.
  10. Faciliter l’apprentissage organisationnel dans les approches adaptatives.
  11. Élaborer des lignes directrices pour le recrutement, l’évaluation et la sélection des leaders d’équipe.
  12. Élaborer et mettre en œuvre des standards pour l’utilisation d’approches adaptatives.
  13. Utiliser le PMaaS* en faisant appel à un tiers pour gérer le PMO.

*Project Management as a Service

Téléchargez les derniers résultats : The Adaptive PMO: Trending Up

Erreurs de débutant commises par le Scrum Master

Le par mopertodans agile, experience sharingLaisser un commentaire

Plongeons-nous dans les erreurs de débutant souvent commises par les Scrum Masters.

Rookie Mistakes Scrum Master Make par Stefan Wolpers

https://age-of-product.com/rookie-mistakes-scrum-masters-make/

1. Ignorer l’importance de l’objectif de sprint

  • Erreur : Traiter l’objectif de sprint comme facultatif ou comme une simple liste de tâches, ce qui entraîne un manque de concentration et de direction pour l’équipe Scrum.
  • Pourquoi c’est une erreur : L’équipe n’a pas d’objectif unifié sans un objectif de sprint clair, ce qui entraîne des efforts fragmentés, une réduction de la valeur globale et des difficultés à mesurer le succès. L’équipe peut se retrouver sans direction, travaillant sur des tâches qui ne s’alignent pas sur l’objectif du produit ou les objectifs stratégiques du produit en général.
  • Opportunité d’apprentissage : Les débutants légitimes se rendent rapidement compte de l’importance d’un objectif de sprint bien défini comme phare guidant les efforts de l’équipe. Il favorise la collaboration et garantit que l’équipe apporte une valeur significative à chaque sprint. Pour vous y entraîner, essayez un atelier sur les objectifs de sprint avant le prochain sprint, au cours duquel l’équipe collabore pour rédiger un objectif clair et cohérent. Apprenez-en plus à leur sujet avec Le fantastique livre de Maarten Dalmijn sur les objectifs de sprint. [Lien d’affiliation Amazon.]
  1. Microgestion de l’équipe
  • Erreur : Agir en tant que chef de tâche ou de projet, superviser et diriger constamment le travail des développeurs.
  • Pourquoi c’est une erreur : Les Scrum Masters doivent servir l’équipe en supprimant les obstacles et en facilitant les processus, et non en contrôlant le travail car les développeurs ont le pouvoir et la responsabilité de faire leur part. La microgestion étouffe l’autonomie et l’innovation de l’équipe, entraînant une baisse du moral et un manque d’appropriation parmi les membres de l’équipe, ce qui entrave finalement la productivité et la créativité.
  • Opportunité d’apprentissage : Les vrais débutants apprennent à faire confiance aux capacités de leur équipe, en se concentrant plutôt sur la possibilité pour l’équipe de s’auto-organiser et de résoudre les problèmes de manière indépendante, ce qui conduit à un engagement plus élevé et à une meilleure résolution des problèmes. Un exercice pour y remédier consiste à vous abstenir de résoudre les problèmes pendant un sprint, mais d’observer et soutenir la progression de vos coéquipiers.
  1. Négliger de renforcer la confiance et la sécurité psychologique de l’équipe
  • Erreur : Ne pas créer un environnement de confiance et de sécurité psychologique où tous les membres de l’équipe se sentent à l’aise pour partager leurs idées et leurs préoccupations.
  • Pourquoi c’est une erreur : Sans confiance et sécurité, les membres de l’équipe sont moins susceptibles de s’engager pleinement, de collaborer efficacement ou de prendre des risques. Négliger la confiance étouffe l’innovation et l’amélioration continue, ce qui conduit à un environnement de travail avec des problèmes non divulgués, un engagement d’équipe terne et une créativité restreinte. Cela peut également entraîner un taux de rotation élevé et une faible satisfaction au travail.
  • Opportunité d’apprentissage : Les Scrum Masters compétents travaillent activement à créer et à maintenir une culture de confiance et de sécurité psychologique. Ils/elles encouragent une communication ouverte et une rétroaction constructive. Un exercice pratique consiste à organiser régulièrement des activités de renforcement de l’esprit d’équipe et des exercices de confiance, tels que le partage d’histoires personnelles de réussite, de défis et d’échecs, afin de développer l’empathie et la compréhension entre les membres de l’équipe.
  1. Se concentrer uniquement sur les indicateurs et les rapports
  • Erreur : En mettant trop l’accent sur les métriques, les OKR et les KPI, le rôle de Scrum Master se transforme en un commis à la saisie de données accablé de rapports excessifs.
  • Pourquoi c’est une erreur : Bien que les mesures puissent fournir des informations précieuses, une insistance excessive peut détourner l’attention du véritable objectif de Scrum, qui est de fournir de la valeur grâce à des efforts de collaboration et à un retour d’information continu basé sur des publications fréquentes et un processus empirique. Une approche axée sur les indicateurs peut également conduire à jouer avec le système, où les membres de l’équipe se concentrent sur l’atteinte des indicateurs plutôt que sur la création d’une véritable valeur, déformant ainsi les priorités de l’équipe.
  • Opportunité d’apprentissage : Les Scrum Masters efficaces équilibrent les indicateurs avec des informations qualitatives, en les utilisant pour soutenir, et non dicter, les décisions et les progrès de l’équipe. Ils/elles comprennent que les mesures sont des outils, et non des objectifs en soi. Pour mettre en œuvre cet objectif, vous devez examiner périodiquement les indicateurs avec l’équipe, en discutant de leur pertinence et de la manière dont ils s’alignent sur la valeur réelle, afin d’assurer une approche équilibrée.
  1. Ne pas responsabiliser l’équipe
  • Erreur : Ne pas donner à l’équipe les moyens de prendre des décisions et de résoudre des problèmes, intervenant souvent pour prendre des décisions ou résoudre des conflits.
  • Pourquoi c’est une erreur : Cette approche sape la confiance de l’équipe et sa capacité à s’autogérer, ce qui entraîne une dépendance vis-à-vis du Scrum Master et une réduction de l’appropriation du travail par l’équipe. Cela entrave la croissance, la créativité et la capacité d’innovation de l’équipe, car les membres ne sont pas encouragés à penser de manière indépendante ou à prendre des initiatives.
  • Opportunité d’apprentissage : Les bons Scrum Masters apprennent à prendre du recul et à faciliter les processus de prise de décision de l’équipe, encourageant les membres de l’équipe à s’approprier leur travail et à développer leurs compétences en résolution de problèmes. Un exercice utile consiste à utiliser une matrice de décision, par exemple, basée sur le résultat d’une session de Delegation Poker, où l’équipe décide de manière collaborative de solutions aux problèmes sans intervention directe du Scrum Master, favorisant ainsi l’autonomie et la confiance.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM

Pratiques utiles pour les débutants afin d’éviter les erreurs de débutant commises par les Scrum Masters

Quelques pistes de réflexion pour l’apprenant en herbe : Il n’est pas nécessaire pour vous de réinventer la roue.

Adoptez l’apprentissage continu : Les Scrum Masters doivent toujours être sur la voie de l’apprentissage continu. Les pratiques Scrum et Agile évoluent, tout comme votre compréhension et leur application. Recherchez des opportunités de formation, de certifications et de réseautage avec d’autres professionnels Scrum. Par exemple, rejoignez la communauté Slack Hands-on Agile ou notre communauté Meetup.

Comprenez le contexte organisationnel : Chaque organisation a sa propre culture et ses propres défis. Comprendre le contexte plus large dans lequel votre équipe fonctionne peut vous aider à mieux soutenir et défendre les pratiques Scrum. Engagez avec les parties prenantes et la direction pour aligner Scrum sur les objectifs de l’organisation. N’oubliez pas que vous ne pouvez pas changer un système au niveau de l’équipe Scrum.

Équilibrez empathie et responsabilité : La constitution d’une équipe performante nécessite un équilibre délicat entre empathie et responsabilité. S’il est essentiel de favoriser un environnement favorable, il est tout aussi important de tenir l’équipe responsable des engagements et des normes de qualité. Les grandes équipes Scrum se tiennent responsables tout le temps ; Ce sont des professionnels.

Soyez un leader serviteur : En tant que Scrum Master, votre rôle principal est de servir l’équipe, par exemple, en supprimant les obstacles, en facilitant la communication et en soutenant l’auto-organisation de l’équipe. Le succès de l’équipe mesure votre succès, alors concentrez-vous sur leur responsabilisation.

L’adaptabilité est essentielle : il n’y a pas deux équipes identiques, et ce qui fonctionne pour l’une peut ne pas fonctionner pour l’autre. Soyez flexible et prêt à adapter votre approche en fonction des besoins et des commentaires de l’équipe. Inspectez et adaptez en permanence non seulement les processus de l’équipe, mais aussi vos propres pratiques et votre état d’esprit.

Favorisez un état d’esprit de croissance : Encouragez une culture où l’échec est considéré comme une opportunité d’apprendre et de grandir. Associé à un état d’esprit de croissance, ceci peut améliorer considérablement la capacité de l’équipe à innover et à s’améliorer continuellement. Célébrez les réussites, mais discutez aussi ouvertement des échecs et des leçons qui en ont été tirées.

Valorisez les boucles de rétroaction: Le retour d’information est la pierre angulaire de l’amélioration continue. Assurez-vous que votre équipe sollicite et donne régulièrement des commentaires, non seulement lors d’événements formels tels que les revues de sprint et les rétrospectives, mais aussi lors des interactions quotidiennes. Un retour pris au sérieux aidera à identifier les problèmes tôt et à promouvoir une culture de transparence et d’amélioration.

La différence essentielle entre les erreurs et les actions d’un débutant et celles de l’imposteur ignorant est la volonté de réfléchir, de s’adapter et de grandir à partir de ses expériences.

Les experts autoproclamés qui comprennent mal et, par conséquent, appliquent mal les principes de Scrum ne parviennent pas à reconnaître et à rectifier leurs erreurs. Dans le même temps, les vrais débutants utilisent ces premiers faux pas comme tremplin pour devenir des Scrum Masters efficaces et respectés.

 

Pourquoi Agile est-il mort ? par Britt Smith

Le par mopertodans agile, leadership1 commentaire

Ne reportez pas tout le blâme sur les leaders !

Agile était autrefois salué comme le sauveur d’une livraison rapide et efficace, et il y avait plus de demandes de coachs agiles que le marché du travail ne pouvait en fournir, mais il a fait face à des critiques et à un déclin important ces dernières années. Bien qu’il soit facile de pointer du doigt le leadership, la disparition d’Agile est un problème multi-facette qui va au-delà des décisions et du soutien du leadership. Explorons les différentes raisons pour lesquelles Agile a eu du mal à tenir sa promesse et son efficacité initiales.

L’essor et le décrochage d’Agile

Agile est apparu au début des années 2000 en réponse aux méthodologies rigides en cascade qui dominaient le développement logiciel. En mettant l’accent sur la flexibilité, la collaboration avec les clients et l’itération rapide, Agile promettait de révolutionner l’industrie. Et pendant un certain temps, c’est ce qui s’est passé. Les équipes ont bénéficié d’une productivité accrue, de délais de livraison plus rapides, d’une plus grande satisfaction des clients et même d’un sentiment d’unité et d’enthousiasme.

Cependant, à mesure qu’Agile s’est étendu des petites équipes dédiées aux grandes organisations, des fissures ont commencé à apparaître. Agile avait été le nouvel outil brillant que tout le monde voulait adopter. Mais cette adoption généralisée s’est souvent produite en silos.

L’adoption des pratiques Agile s’est concentrée uniquement sur l’espace technologique, laissant d’autres parties de l’organisation derrière elles.

Ce parcours cloisonné est devenu un énorme goulot d’étranglement, car le reste de l’organisation a eu du mal à suivre le rythme des changements rapides et des exigences des équipes Agile.

Mauvaise interprétation et mauvaise application

L’un des principaux problèmes conduisant au déclin d’Agile est la mauvaise interprétation et la mauvaise application généralisées de ses principes. De nombreuses organisations ont adopté les pratiques Agile de manière superficielle, sans vraiment comprendre ou s’engager envers ses valeurs.

Les stand-ups quotidiens, sprints et backlogs sont devenus un autre ensemble de tâches plutôt que des outils pour favoriser la collaboration et l’innovation.

De plus, l’utilisation des story points s’est transformée en une compétition, où les équipes étaient récompensées en fonction du nombre de story points qu’elles avaient complétés au cours d’un sprint.

Dans certains cas, les entreprises ont mis en œuvre Agile comme ordre venant d’en haut, sans fournir la stratégie de management du changement nécessaire pour soutenir le changement culturel nécessaire à son succès. Cela a conduit à la désillusion des équipes, qui considéraient Agile comme une autre mode de management plutôt que comme un changement significatif dans leur façon de travailler.

Résistance culturelle

Agile nécessite un changement culturel important, ce qui peut être un obstacle majeur dans les organisations établies. L’évolution vers des équipes auto-organisées et une prise de décision décentralisée contraste fortement avec les structures hiérarchiques traditionnelles. La résistance des cadres intermédiaires, qui se sentent souvent menacés par la perte de contrôle, peut étouffer l’adoption d’Agile.

De plus, l’accent mis par Agile sur la transparence et la responsabilité peut être inconfortable pour les équipes habituées à fonctionner sans sécurité psychologique et sans confiance au sein de l’équipe et avec la direction.

Sans un environnement favorable, ces changements culturels peuvent entraîner des frictions et, en fin de compte, saper les initiatives Agile.

Des stratégies de management du changement, telles que l’établissement de stratégies d’intervention et d’encadrement pour gérer la résistance, auraient favorisé les changements culturels. Par exemple, des séances de coaching sur mesure, des ateliers de renforcement de l’esprit d’équipe, des forums ouverts pour recueillir des commentaires et un soutien continu de la direction auraient pu atténuer les craintes et créer une culture plus tolérante.

Trop d’importance accordée aux outils et aux processus

Au fur et à mesure que l’agilité gagnait en popularité, une pléthore d’outils et de processus ont émergé pour soutenir sa mise en œuvre. Bien que ceux-ci puissent être bénéfiques, une dépendance excessive à leur égard peut entraîner une perte de concentration sur les principes fondamentaux d’Agile.

Les équipes s’enlisent dans la gestion des outils plutôt que dans la création de valeur.

De plus, la commercialisation d’Agile a conduit à la prolifération des certifications et des cadres de travail, créant un paysage fragmenté où l’essence d’Agile est souvent perdue. L’accent est mis sur l’amélioration de la collaboration et de l’adaptabilité pour cocher des cases et obtenir des certifications.

Le rôle du leadership

Bien que le leadership ne soit pas le seul responsable du déclin d’Agile, il joue un rôle crucial. Les leaders qui ne comprennent pas ou ne soutiennent pas les principes Agile peuvent entraver son succès. L’adoption efficace d’Agile nécessite des dirigeants prêts à défendre la cause, à fournir les ressources nécessaires et à favoriser une culture de confiance et d’autonomisation.

Cependant, il est également important de reconnaître que les leaders sont souvent contraints par des pressions et des exigences organisationnelles plus larges.

Le besoin de résultats à court terme et le respect des mesures traditionnelles de réussite peuvent entrer en conflit avec la nature itérative à long terme d’Agile.

Par conséquent, il est essentiel d’avoir un coach de haut niveau spécialisé dans le changement organisationnel et l’agilité pour guider le leadership. Un tel coach peut aider à combler le fossé entre la vision de la direction et l’exécution de l’équipe, en veillant à ce que les principes Agile soient appliqués efficacement et que le changement culturel soit géré en douceur.

Le vrai problème : l’absence de changement stratégique

De nombreuses organisations ont embauché des professionnels ayant des références et une expérience en Agile, mais ont négligé un élément essentiel à une transformation réussie : Une stratégie de changement.

Sans un plan clair pour le changement organisationnel nécessaire au succès d’Agile, ces efforts sont devenus fragmentés et ont souvent conduit à une mise en œuvre incohérente.

Les organisations ont commencé à étendre leur adoption d’Agile sans former d’alliances et obtenir le soutien de tous les secteurs touchés par le changement. En conséquence, les méthodes de travail Agile sont devenues une autre case à cocher, certaines équipes résistant complètement à Agile, disant : « Je n’ai pas le temps pour Agile ! ». L’absence d’une stratégie cohérente de changement culturel et organisationnel a donné lieu à des pratiques Agile qui n’avaient d’Agile que le nom.

Aller de l’avant : Apprendre de l’échec

La disparition d’Agile dans de nombreuses organisations ne signifie pas l’échec de ses principes, mais plutôt les challenges dans leur mise en œuvre dans des environnements variés et complexes. Pour aller de l’avant, il est essentiel de tirer les leçons de ces expériences et de souligner l’importance d’une stratégie globale de management du changement pour véritablement intégrer l’agilité dans la culture de l’organisation. Agile est une approche de travail très puissante, et ses bénéfices peuvent s’étendre au-delà du développement logiciel, répondant ainsi à une idée fausse mais répandue.

  1. Adoptez la véritable agilité : Concentrez-vous sur les valeurs et les principes sous-jacents d’Agile plutôt qu’adhérer de manière rigide à des pratiques spécifiques.
  2. Investissez dans la culture : Donnez la priorité au changement culturel, en favorisant un environnement de collaboration, de transparence et d’amélioration continue. Mettez en œuvre des stratégies de management du changement qui soutiennent ce changement culturel, en veillant à ce qu’Agile soit ancré dans l’ADN de l’organisation.
  3. Engagez les leaders, la direction : Assurez-vous que les leaders sont formés à Agile et s’engagent à soutenir sa mise en œuvre par des actions, et pas seulement par des paroles. Avoir un coach de haut niveau ayant une expertise en changement organisationnel et en agilité peut guider efficacement le leadership.
  4. Étendez Agile au-delà de l’informatique : Reconnaissez qu’Agile n’est pas seulement destiné au développement de logiciels. Appliquez les approches de travail Agile à d’autres domaines de l’organisation, en brisant les silos et en favorisant une culture agile holistique.
  5. Développez un plan stratégique : Créez une stratégie complète pour l’adoption d’Agile qui comprend des objectifs, des délais et des mesures de réussite clairs. Ce plan devrait impliquer la formation d’alliances et l’obtention du soutien de toutes les régions touchées par le changement.

Conclusion : Agile n’est pas mort, mais sa vie ne tient plus qu’à un fil !

La morale de l’histoire est qu’Agile n’est pas vraiment mort, mais qu’il ne tient qu’à un fil. La vérité est que de nombreuses organisations ont embauché des coachs Agile pour former et coacher les équipes sans élaborer de plan stratégique pour le changement nécessaire au succès d’Agile. En comblant ces lacunes stratégiques et culturelles, et en étendant les pratiques Agile au-delà du développement logiciel, les organisations peuvent continuer d’exploiter les avantages d’Agile et s’adapter aux exigences en constante évolution du paysage business moderne.

Britt Smith

Human Centered Agility (Agilité centrée sur l’humain)

Fervente défenseuse de la résilience organisationnelle, Britt se consacre à donner aux entreprises les moyens de naviguer dans l’environnement business dynamique d’aujourd’hui avec force et agilité.

Britt s’est donnée pour mission d’intégrer l’agilité centrée sur l’humain dans les organisations, permettant aux leaders et aux équipes de manager efficacement le changement et de s’adapter aux défis avec innovation et résilience.

Elle est motivée par la vision de réinventer l’avenir du travail. Un avenir où le développement centré sur l’humain est primordial, où les équipes excellent dans un contexte de changement continu et où les organisations non seulement survivent mais prospèrent en donnant la priorité à leurs employés.

« Intégrer l’intelligence artificielle dans la gestion de projets Agiles » par Leon Herszon, Ph.D.

Le par mopertodans agile, pointeurs utilesLaisser un commentaire

Voici un livre blanc qui donne un aperçu de la manière dont l’intelligence artificielle remodèle la gestion des projets Agiles.

Au fur et à mesure que les technologies de l’IA évoluent, elles offrent des outils permettant d’améliorer les processus de prise de décision, d’automatiser les tâches routinières et de personnaliser les interactions avec les parties prenantes. Cette fusion de l’IA avec les méthodologies Agiles permet non seulement d’augmenter l’efficacité des processus, mais aussi de naviguer plus efficacement dans la complexité des demandes de projets modernes.

Lire la suite

Leon Herszon, Ph.D.

Dr. Leon Herszon, MSc, PhD, PMP, CSM, CSPO, DASSM. Dr. Herszon is a highly accomplished, versatile, and respected executive with over 30 years of extensive achievements within diverse environments utilizing exemplary management, analytical, organizational, and people skills. He has experience leading teams to improve performance and manage business transformation focused on agility, transparency, teamwork, experimentation, and innovation. Dr. Herszon’s doctoral research explored factors that contribute to project complexity and proposed a model to manage complexity.

Dr. Herszon performed roles as executive and managing director, Chief Agility Officer, entrepreneur, portfolio, program and project director, business transformation leader, corporate educator, and is currently the Head of IIL’s global consulting practice. He is also an Adjunct Professor at the prestigious Rutgers Business School. Dr. Herszon can communicate in English, French, Portuguese, German, and Spanish, and is also a several times Ironman triathlon finisher.