articles, méthodes, partages d'expérience et rdv du management de projets et de l'agilité
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.
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.
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.
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.
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.
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 :
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.
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.
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.
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ésDans 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.
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.
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 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.
Voici quelques moyens pratiques pour toute équipe produit d’adopter les valeurs Scrum :
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.
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.
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 :
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.
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.
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.
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/
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.
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é.
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.
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.
Au fil des ans, j’ai remarqué 2 flux standard de développement de produits dans les entreprises, quel que soit leur cadre :
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é
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
Comment les approches de management de projet Prédictive, Agile, Lean/Kanban et Hybride peuvent-elles être représentées dans les principaux domaines du management de projet.
Nous devrions considérer les approches de management de projet comme une palette d’options. Prédictive, Agile et Lean/Kanban forment les limites. L’hybride est le vaste espace intérieur.
Le premier article de cette série décrivait les limites et le mélange de couleurs des approches :
L’approche projet devient une caractéristique déterminante dans la description des phases du projet et de la manière dont elles sont exécutées.
Le prédictif suit une approche rigide et séquentielle. Les passages de points de contrôle marquent l’achèvement de chaque phase.
Scrum se caractérise par une série d’itérations de conception-construction-test (sprints), qui durent généralement deux semaines.
Les projets prédictifs-hybrides suivent la structure prédictive. Cependant, les phases peuvent se chevaucher. Un modèle typique est le chevauchement de la conception avec le développement, et du développement avec les tests. Les examens de fin de phase peuvent être informels ou ne pas être utilisés.
Les projets hybrides-agiles suivent un modèle de type Scrum mais sont soumis à des contraintes de projet plus traditionnelles. Le développement est itératif, mais les tests peuvent être réalisés en dehors des sprints. La livraison peut se faire à la fin plutôt que progressivement.
Scrum-fall est un modèle hybride qui suit une approche séquentielle dans la planification, les exigences et la conception, mais utilise ensuite l’approche itérative pendant la phase de construction.
Kanban se concentre principalement sur le flux de travail. Les équipes Agile utilisent un tableau Kanban pour gérer la progression des fonctionnalités et des histoires utilisateur. Les équipes prédictives et hybrides peuvent également utiliser des tableaux Kanban. Ils peuvent être utilisés pour gérer le flux de documentation ou suivre les activités de développement et de test.
Prédictif est optimisé pour les problèmes simples et complexes avec des exigences clairement définies.
Scrum est conçu pour résoudre des problèmes complexes dont la solution n’est peut-être pas immédiatement apparente. Des informations supplémentaires, des commentaires et des améliorations sont nécessaires pour comprendre le problème et concevoir la solution.
L’approche Kanban basée sur les flux prend facilement en charge les problèmes simples et compliqués, car les étapes du processus sont définies et bien comprises. L’objectif est de maximiser la création de valeur avec le délai de livraison le plus court.
Les préférences organisationnelles et d’autres considérations externes guident souvent la décision du choix de l’approche de projet.
Les organisations ont tendance à utiliser l’approche dominante, quel que soit le type de problème.
Les projets prédictifs se caractérisent par une portée, un échéancier et un coût fixes. La triple contrainte classique affirme qu’un changement de portée nécessite un changement correspondant de délais ou de coûts. Par conséquent, le changement est géré au moyen d’un processus formel et structuré.
Les projets agiles renversent la triple contrainte. La portée est émergente, et le temps et le coût peuvent être fixes. La limite de temps du projet limite la portée. Le Product Owner et les parties prenantes examinent et redéfinissent régulièrement les priorités des fonctionnalités requises. Un processus léger peut être utilisé pour gérer le changement.
La plupart des organisations qui utilisent des approches hybrides conservent l’état d’esprit prédictif à portée fixe, ce qui crée des tensions avec la portée émergente d’Agile. Pour beaucoup, abandonner la triple contrainte s’apparente à s’ interroger sur la loi de la gravité. L’hybrid-agile a du mal à concilier le principe « embrasser le changement » du Manifeste Agile avec un état d’esprit fixe.
Les projets prédictifs traditionnels ont un engagement limité des parties prenantes. L’engagement est élevé lors de la collecte des exigences et pendant les phases de tests utilisateur et de mise en production. L’engagement est léger et se limite généralement à des mises à jour de statut d’avancement pendant les phases d’exécution.
L’agilité valorise un engagement régulier et cohérent des parties prenantes. Le Manifeste prône la « collaboration client ». Le Product Owner est la voix des clients et fait partie intégrante de l’équipe de développement.
Les projets hybrides-prédictifs impliquent un engagement plus fréquent des parties prenantes, un modèle qui existe depuis l’avènement de l’approche « en cascade ». La conception conjointe d’applications (Joint Application Design / JAD) et d’autres pratiques ont été élaborées pour impliquer les parties prenantes dans la solution et fournir une rétroaction précoce.
Les projets hybrides-agiles adoptent les principes d’un engagement régulier.
L’approche traditionnelle de management descendante est associée aux projets prédictifs. Le/la manager de projet est responsable de la réussite du projet et anime l’équipe. Les managers de projet sont habilités à prendre des décisions, à attribuer des tâches et à gérer l’exécution du travail du projet.
Agile adopte une approche résolument différente de management. Les équipes agiles s’auto-organisent. Le/la Scrum Master est un facilitateur et un leader serviteur dont le rôle principal est d’aider l’équipe et l’organisation à mûrir. Un principe de Scaled Agile consiste à « libérer la motivation intrinsèque des travailleurs du savoir ».
La théorie X et Y de Douglas MacGregor incarne la dichotomie entre les approches prédictives et agiles.
L’approche de management des projets hybrides dépend souvent de facteurs externes. La phase de conception d’un projet de construction peut chercher à libérer les énergies créatives, tandis que la phase d’exécution peut se concentrer sur le respect du plan. La culture, la structure de l’équipe et les personnalités individuelles jouent également un rôle essentiel. J’ai observé des leaders participatifs dans des projets prédictifs et des leaders autocratiques dans des projets agiles.
Les projets prédictifs nécessitent une documentation importante et un respect strict des processus. L’approche a évolué en partant des projets de construction, où le coût du changement est élevé. Des spécifications de conception détaillées sont nécessaires et constituent le principal moyen de transmettre l’information. Les normes réglementaires ou organisationnelles internes peuvent également être des considérations importantes.
L’agilité a évolué à partir du développement de logiciels, où le coût du changement est faible. De petites équipes pluridisciplinaires peuvent développer efficacement des solutions à des problèmes complexes. Par conséquent, le manifeste Agile a remis en question la nécessité d’une « documentation excessive » et a valorisé « les individus et les interactions plutôt que les processus et les outils ».
Agile ne rejette pas toute documentation ou processus. Il a adopté une norme « minimalement suffisante », c’est-à-dire la sélection du niveau approprié de processus et de documentation requis pour un projet. Une grande équipe géographiquement dispersée qui développe un système critique nécessite plus de contrôle qu’une petite équipe colocalisée qui développe une application non critique.
Les projets hybrides doivent établir processus et documentation pragmatiques et contextuels (empruntant à Disciplined Agile). Les principes du Lean et du Kanban peuvent guider ce processus, en éliminant le gaspillage et en apportant de la valeur dans les délais les plus courts possibles.
Les projets hybrides-agiles sont souvent confrontés à des contraintes externes, telles que des exigences contractuelles, réglementaires ou organisationnelles, par exemple, le développement de logiciels agiles sur un projet gouvernemental. Les contraintes contractuelles peuvent nécessiter plus de documentation, des tests d’acceptation hors sprint ou un processus de management du changement plus structuré.
© 2024, Alan Zucker ; Project Management Essentials, LLC
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.
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.
Les meilleures pratiques du management de projet, programme et portefeuille de projets, partage d’expériences, questions/réponses sur les thèmes de ce domaine qui vous intéresse.
Ce blog est également ouvert aux discussions sur le leadership, l’innovation, les petites idées qui permettent de se faciliter la vie professionnelle et de progresser.
Ci-dessus, un extrait du contenu du tout premier billet, le 26 Juin 2009 !
Le blog DantotsuPM est né de mon envie de partager (dans la continuité de la création du PMI® France-Sud dans les années 2000).
Comme beaucoup d’entre vous qui suivez mes publications, je cherche en permanence à améliorer les multiples compétences qui permettent de progresser dans ma vie et mes pratiques.
C’est d’ailleurs de là que vient le nom du blog car le mot Dantotsu que j’ai croisé lors de voyages professionnels au pays du soleil levant signifie en Japonais « rechercher en permanence le meilleur du meilleur ».
J’ai accolé PM à Dantotsu pour Project Management, ma passion : DantotsuPM était né !
Je sélectionne, traduit en français et publie sur ce blog des billets liés au management de projets, programmes, Project Management Office (PMO) et Portfeuilles de projets (PPM), aux soft skills, à l’agilité, à l’analyse des besoins business et au leadership.
Je m’efforce d’illustrer ces articles avec des images, vidéos, pointeurs utiles, partages d’expérience, bonnes pratiques, méthodes, outils, astuces, annonces de rencontres et wébinaires….
Vous pouvez suivre tous ces contenus directement sur ce blog https://dantotsuPM.com/ , ou sur vos médias sociaux favoris : Twitter, LinkedIn ou même Pinterest !
Si votre société souhaite accroitre sa visibilité auprès des managers de projets et de leurs organisations, devenez sponsor-partenaire du blog DantotsuPM.
Découvrez ou relisez les billets les plus appréciés de la dernière année pour vous faire une meilleure idée de ce que ce blog peut éventuellement vous apporter.
Il y a déjà plus de 4000 billets en ligne et j’en publie un nouveau chaque jour…
Je vous invite donc à venir y piocher à votre rythme et selon vos besoins.
Visitez également l’espace ressources gratuites qui contient de nombreux pointeurs vers des documents utiles aux managers de projets.
J’espère que vous apprécierez d’utiliser les catégories qui regroupent les billets autour de grands thèmes ainsi que les mots clés qui rendront vos recherches plus faciles (dans la colonne de droite).
Voilà, je vous souhaite de belles lectures et de riches échanges et contributions à notre communauté de passionné.e.s du management de projets.
Le management de projet hybride vient de connaître son heure de gloire !
Le Project Management Institute Pulse of the Profession® 2024 déclare que l’approche hybride (32 %) est maintenant la deuxième approche la plus couramment utilisée. L’approche prédictive (44 %) détient toujours une avance considérable. Et l’utilisation d’Agile (26 %) perd 2 points.
Avant de nous enthousiasmer, le rapport sur l’état de l’agilité (State of Agile Report) identifie différentes tendances. et ses répondants préfèrent l’agilité (70 %) à l’hybride (47 %) et à l’approche prédictive Waterfall (35 %).
Plusieurs facteurs peuvent être à l’origine de ces tendances récentes :
Agile et Waterfall sont les angles du continuum de management de projet, et l’hybride en est le vaste milieu. La plupart des organisations ne pratiquent ni l’agilité pure ni l’approche prédictive ; L’hybride est donc une description plus exacte.
L’intérêt pour les hybrides est nouveau et augmente rapidement. Le format de l’ examen PMP a changé en janvier 2020. Dans le nouveau test, 27 % des questions étaient hybrides et 23 % agiles. Cela a déclenché une explosion du trafic de recherche Google pour le « management de projet hybride ».
La formation agile a atteint un point de saturation. Scrum Alliance compte 1,5 million de certificié.e.s, et Scaled Agile (SAFe) plus d’un million de personnes formées. En comparaison, il y a environ 1,5 million de managers de projet certifiés (PMP).
Agile a peut-être « heurté le mur ». L’agilité est fondamentalement un état d’esprit, pas une méthodologie. Les principaux défis de l’adoption de l’agilité sont organisationnels et culturels. Le rapport sur l’état de la culture Agile montre que seuls 10 % des leaders font preuve des qualités souhaitées.
La profession de manager de projet se décrivait historiquement en termes discrets. Waterfall avait une emprise quasi monopolistique jusqu’à l’avènement de l’agilité. La profession est alors entrée dans un monde bipolaire : agilistes contre traditionalistes.
En réalité, le management de projet est désordonné. On peut le décrire comme « la cathédrale versus le bazar ». Les développeurs de cadres de travail parlent dans les termes absolutistes de la cathédrale, tandis que les managers de projet mélangent les pratiques comme on le voit dans un bazar.
Hybride nous permet de donner un nom à ce mélange de la vaste palette de couleurs. Prédictif, agile et Lean/Kanban peuvent être considérés comme les pointes d’un triangle avec un éventail presque infini d’options.
Le spectre des approches peut être étiqueté comme suit :
Winston Royce a décrit pour la première fois l’approche waterfall en 1971 comme une méthodologie de développement logiciel basée sur son expérience de la construction de systèmes pour les engins spatiaux. Il a défini une série d’étapes en cascade allant de la collecte des besoins aux opérations de déploiement.
L’établissement précoce des exigences et des spécifications de conception est une caractéristique essentielle des projets prédictifs. Cette approche est utilisée dans la construction et les efforts similaires où le coût du changement est élevé. Les projets ont souvent des passages de phase rigides pour confirmer la viabilité et l’exhaustivité avant de passer à l’étape suivante.
Les équipes de projet travaillent sur leurs composants individuels et intègrent et testent périodiquement leur travail. Le rôle principal du manager de projet est de coordonner et de superviser les efforts de ces équipes alignées sur le plan fonctionnel. Une collaboration inter-équipes limitée est nécessaire.
L’engagement des parties prenantes est plus important au début du projet, lorsque les exigences sont collectées et analysées. Tout au long du cycle de développement, il y aura des réunions et des revues périodiques de l’état d’avancement. Il faut souvent des années avant que les parties prenantes ne voient le produit fini.
L’agilité est un état d’esprit, pas une méthodologie. De multiples cadres de travail frameworks (Scrum, eXtreme Programming, DSDM, Scaled Agile (SAFe), Disciplined Agile, etc.) permettent aux équipes de fournir de la valeur plus rapidement et de manière plus prévisible. Les cadres de travail ne sont pas monolithiques et représentent un éventail d’approches et de pratiques.
Scrum est la méthodologie la plus couramment utilisée et ancre cet angle du triangle. Scrum décrivait à l’origine comment développer un nouveau produit et a ensuite été adopté pour des projets logiciels complexes par Jeff Sutherland et Ken Schwaber.
Royce s’est rendu compte que les cycles de test tardifs et les délais de livraison prolongés de l’approche prédictive waterfall posaient un risque important. Scrum atténue ces risques grâce à son approche itérative et incrémentielle. Les cycles de développement sont généralement limités à 2 semaines, après quoi les parties prenantes fournissent des retours. Le retour d’information est utilisé pour adapter et ajuster le produit et éviter le piège du « je le saurai quand je le verrai ».
Les équipes Scrum sont petites (moins de 10), auto-organisées et exploitent les énergies créatives des travailleurs du savoir. Le manager de projet de type « commande et contrôle » est remplacé par le scrum master serviteur, dont le rôle principal est d’aider l’équipe à mûrir. Le Product Owner est un membre à part entière de l’équipe et représente la voix du client.
Le Lean et le Kanban sont un ensemble de principes et de pratiques, datant des années 1950, développés à l’origine par Toyota. Le Lean se concentre sur la création de valeur et l’élimination du gaspillage. Kanban est une sous-pratique Lean qui se concentre sur la création et la gestion de flux.
Lean/Kanban est la troisième extrémité du triangle. Bien qu’ils soient souvent associés à l’agilité, leurs pratiques sont universelles. Ceci est fondamental pour la plupart des frameworks agiles, et les équipes agiles très matures se concentrent souvent sur le flux (Kanban). Dans Disciplined Agile, le Lean est défini comme un cycle de vie autonome. SAFe 6.0 sépare l’équipe Kanban de son approche Scrum.
L’hybride-prédictif suit principalement la structure linéaire waterfall et intègre des pratiques de type agile. La structure conception-construction-test-déploiement prend en charge efficacement de nombreux types de projets. Cependant, les approches purement prédictives peuvent être rigides et reposer sur l’hypothèse forte que la solution peut être définie dès le début du projet.
Les équipes logicielles ont commencé à utiliser des approches en « waterfall modifié » dans les années 1970, bien avant l’avènement de l’agilité. Ils ont utilisé des approches itératives et progressives pour mobiliser les intervenants. Des sessions de prototypage et de conception d’applications conjointes (JAD) ont permis aux utilisateurs et aux développeurs de collaborer sur la solution.
Même la construction, qui est le bastion de l’approche en cascade, a adopté l’hybride. Traditionnellement, la conception et la construction sont des activités spécialisées et séparées. Les firmes d’architecture et d’ingénierie créent des plans et des devis qui sont ensuite exécutés par les entreprises de construction. Cependant, la conception-construction combine ces deux activités en un seul contrat exécuté par une seule entreprise. Cette approche améliore la collaboration, la coordination et la communication. Les avantages sont des cycles de développement plus courts, des coûts réduits, moins d’erreurs et une responsabilité claire.
L’approche prédictive-hybride peut être décrite comme penchant davantage vers la structure waterfall et intégrant des pratiques agiles. Il existe plusieurs modes d’utilisation. L’un est un projet structuré qui utilise des techniques agiles telles que des stand-ups quotidiens, une documentation minimale suffisante et un engagement fréquent des parties prenantes. Un autre modèle est la conception initiale de haut niveau avec un développement itératif et/ou une livraison incrémentielle.
De nombreuses organisations prétendant être agiles utilisent probablement une approche hybride-agile. Elles suivent un modèle de type Scrum et utilisent de nombreuses pratiques agiles. Cependant, des contraintes empêchent l’adoption de l’état d’esprit agile. Ces limites sont souvent liées à la culture, à la structure et à la nature du travail de l’organisation.
Les grandes entreprises bureaucratiques, les agences gouvernementales et les organisations à faible maturité agile correspondent à ce modèle. Elles peuvent suivre de nombreuses pratiques de Scrum ; Cependant, elles font face à de nombreux défis, notamment :
“PMI”, the PMI logo, “PMP”, “PMBOK”, “PM Network”, “Project Management Institute” and “Pulse of the Profession” are registered marks of Project Management Institute, Inc.
Il n’est pas nécessaire de devenir membre du PMI pour en profiter, même si personnellement je vous le recommande. C’est du 100% gratuit pour toutes et tous.
Cette série comprend des cours tels que PMI Kick-off, pour apprendre les bases du management de projets, une mini-formation sur les bases de l’agilité avec Scrum et Disciplined Agile, ou une découverte d’approches de résolution de problèmes sur les biais cognitifs. Sans oublier bien sûr le cours de présentation de l’IA générative pour les managers de projet. Et plus encore…
Tout est projet dans votre vie pro comme perso. Et ceci s’applique à toutes les personnes et de tous les âges. Faites découvrir ces formations (en anglais) à vos collègues, amis et membres de votre entourage, ils vous en remercieront.
Bien sûr, les membres du PMI ont accès à de nombreuses ressources additionnelles gratuitement dont la plateforme d’IA PMI : Infinity
PMI is a registered mark of Project Management Institute, Inc.
La session d’affinement de l’arriéré de produit n’est pas un événement Scrum obligatoire, mais une pratique complémentaire très utile qui aide l’équipe Scrum et ses parties prenantes à parvenir à une compréhension commune de l’arriéré de produit, de l’objectif produit et des priorités.
La session d’affinement de l’arriéré de produit (Product Backlog Refinement) n’est pas un événement Scrum officiel, mais c’est une activité cruciale qui aide les équipes Scrum à parvenir à une compréhension commune des éléments de l’arriéré de produit en préparation à la planification du sprint. Les équipes qui adoptent l’amélioration de l’arriéré de produit comme pratique complémentaire ont tendance à avoir des événements de planification de sprint plus fluides. Le nombre de sessions de raffinement au sein d’un sprint dépend de divers facteurs tels que l’état de l’arriéré de produit, la maturité du produit, la disponibilité et l’expérience de l’équipe Scrum.
Il y a de nombreuses de façons de faciliter une session d’affinement de l’arriéré de produit, mais je présente ici certaines des activités que j’attendrais d’une équipe Scrum dans l’une de ces sessions. Celles-ci ne sont pas présentées dans un ordre particulier.
Dans la session d’affinement de l’arriéré de produit, l’équipe Scrum doit chercher à décomposer les PBI jusqu’à ce qu’ils soient suffisamment petits pour tenir dans le sprint.
La définition de terminé (done) doit être utilisée comme guide pour discuter du travail à accomplir pour chaque PBI du sprint.
Il y a de nombreuses techniques qui peuvent être utilisées pour décomposer les PBI, mais je préfère le découpage vertical des PBI, car l’équipe Scrum a une plus grande probabilité de fournir un incrément utilisable à partir d’un PBI, lorsque le PBI est découpé verticalement.
Les équipes Scrum qui pratiquent l’estimation en tant que pratique complémentaire doivent fournir une prévision de l’effort requis pour fournir des PBI en utilisant la définition de terminé (done) pour le produit comme guide.
Pour ces équipes, l’estimation des PBI aide l’équipe Scrum à sélectionner des éléments de l’arriéré de produit jusqu’à la pleine capacité des développeurs. Si des estimations ont déjà été fournies pour les PBI, l’animateur de la session d’affinement de l’arriéré de produit doit reconfirmer que chaque développeur reste à l’aise avec l’estimation qui a été précédemment enregistrée sur le PBI.
Certaines techniques courantes d’estimation incluent Story Pointing, T-Shirt Sizing and Planning Poker.
Les critères d’acceptation devraient être revus pour en vérifier la clarté et l’exhaustivité lors de la séance d’amélioration de l’arriéré de produit. L’animateur doit inviter les participants à la session d’amélioration de l’arriéré de produit à poser des questions et à demander des éclaircissements si nécessaire. Il y a des cas où l’équipe n’arrive pas à s’entendre sur les critères d’acceptation, en particulier pour un PBI complexe ; L’équipe Scrum pourrait alors trouver utile de réexaminer le « pourquoi ? ». Le Product Owner doit être en mesure d’exprimer clairement la valeur du PBI ; D’après mon expérience, une fois que la valeur est transparente pour tous les participants, les développeurs peuvent s’autogérer pour déterminer les détails de ce qui doit être fait et comment le travail serait accompli.
Cela n’aurait aucun sens d’intégrer une histoire utilisateur / story avec des dépendances et des blocages dans un sprint, car cette story ne sera probablement pas terminée dans le sprint. L’équipe Scrum doit discuter de toutes les dépendances et de tous les bloqueurs pour s’assurer que tout le monde a une compréhension commune des dépendances et des blocages ; L’équipe Scrum doit mettre en place un plan pour résoudre ces dépendances et ces blocages. Le cas échéant, ces dépendances et blocages doivent être représentés dans l’arriéré de produit et attribuées aux personnes qui travaillent à les supprimer. À titre indicatif, l’équipe Scrum ne doit PAS présenter d’éléments avec des dépendances et des blocages non résolus pour la planification du sprint, sauf s’il existe un plan pour résoudre ces obstacles au sein du sprint.
Le Product Owner est responsable de la priorisation de l’arriéré de produit et il existe un certain nombre de raisons qui peuvent être prises en compte telles que la Valeur, la Priorité, la Cohérence Business, la Cohérence Technique, etc. Le Product Owner doit prendre l’habitude de garder l’arriéré produit ordonné à tout moment et une session telle que la session d’affinement de l’arriéré de produit est un bon moment pour examiner et mettre à jour l’ordre des PBI dans l’arriéré de produit.
Comme indiqué dans l’introduction, la session d’amélioration de l’arriéré de produit n’est pas un événement Scrum obligatoire, mais une pratique complémentaire très utile qui aide l’équipe Scrum et ses parties prenantes à parvenir à une compréhension commune de l’arriéré de produit, de l’objectif produit qu’il contient et des éléments de l’arriéré de produit qui ont émergé pour atteindre l’objectif produit.
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.
Peu importe ce que les membres de votre équipe sont en train de faire, vous pensez qu’ils devraient être en train de travailler sur autre chose.
Les managers ont un rôle crucial à jouer dans les organisations, mais les managers peuvent vouloir trop aider et ainsi entraver un travail efficace.
Souvent, les méthodes de travail sont une tentative d’optimisation de l’efficacité, ce qui affecte finalement négativement la réelle efficacité de l’équipe. Les comportements énumérés ci-dessus pourraient être appropriés dans un domaine complexe tel que l’industrie manufacturière, où les managers ont le besoin de maximiser l’utilisation de « machines ». Dans un domaine complexe comme le développement de produits, ces types de comportements ont tendance à avoir des effets néfastes sur les gens et sont contre-productifs. Les gens sont le produit de leur environnement et les managers micro-managent pour une myriade de raisons, notamment la pression des dates, le manque de confiance, les équipes immatures, entre autres.
Il existe une meilleure façon de manager les personnes ! et le Scrum Framework est un cadre de management d’équipe que je recommande pour apprendre à construire des individus efficaces qui travaillent au sein d’équipes efficaces pour une organisation efficace.
Praticien agile et agnostique ainsi qu’un formateur professionnel Scrum avec Scrum.orgNous proposons des ateliers Scrum et Agile Leadership pour commencer à désapprendre le micro-management et apprendre à gérer les personnes par des objectifs sur le lieu de travail.
Mener un spike technique à l’aide du développement axé sur le comportement
https://samadesoga.me/posts/driving-a-technical-spike-using-bdd/ de Sam Adesoga
La plupart des méthodologies agiles prévoient l’application d’un Technical Spike pour explorer une nouvelle technologie ou les zones à risque d’un produit. La méthodologie SAFe (Scaled Agile Framework) définit le Spike comme un type d’histoire d’exploration et de catalyseur.
Il s’agit notamment de :
Le Technical Spike est de nature exploratoire et il est contradictoire d’essayer d’estimer la complexité d’un travail qui n’est pas bien compris. D’après mon expérience, la plupart des équipes préféreraient limiter dans le temps les efforts nécessaires pour réaliser un Technical Spike.
Il y a quelques semaines, j’ai eu une conversation avec un développeur qui était à mi-chemin d’un spike et j’ai eu un moment « ah-ha », et cet article est une tentative d’expliquer ce qui pourrait être une approche alternative aux Technical Spikes.
Je suggérerais au Product Owner / Business Analyst en collaboration avec un membre technique de l’équipe, par exemple un architecte, un responsable technique, de définir les exigences de haut niveau à l’aide de la méthodologie de développement axée sur le comportement.
Comme pour tout le reste, il n’y a pas de solution miracle, mais il faut veiller à ne pas aller trop loin avec les exigences. Étant donné qu’il s’agit d’un Technical Spike, il est nécessaire de s’assurer que l’exigence est à un niveau très élevé suffisant pour décrire les objectifs du Technical Spike et qu’elle ne soit pas prescriptive.
Cela semble bien fonctionner pour ce projet, alors n’hésitez pas à l’essayer.
Praticien agile et agnostique ainsi qu’un formateur professionnel Scrum avec Scrum.org
Scrum et d’autres cadres d’agilité se basent sur des équipes auto-organisées / autogérées.
L’agilité organisationnelle implique que l’ensemble de l’organisation soit un réseau interdépendant d’équipes autogérées. De telles organisations nécessitent un type de leadership différent aux différents niveaux de l’organisation.
Ma phrase préférée dans le Manifeste Agile est « Les individus et les interactions plutôt que les processus et les outils ». Cela implique que les leaders doivent créer un environnement permettant aux équipes de collaborer au sein des équipes et entre les équipes.
Dans cet article, je décris 5 caractéristiques des leaders qui réussissent à créer un environnement propice à l’épanouissement des équipes agiles.
Ces leaders démontrent aux équipes qu’elles peuvent et doivent prendre des décisions qui affectent leurs équipes. Ils veillent à ce que leurs équipes possèdent les compétences appropriées et disposent en permanence d’informations qui leur permettent de s’autogérer.
Les équipes autonomes ont le pouvoir de prendre des décisions qui affectent leur façon de travailler et le produit qu’elles créent. Elles ont également la permission d’expérimenter et d’échouer (d’apprendre).
La confiance est une condition fondamentale pour que l’agilité prospère. Les leaders qui ont peu confiance en l’équipe ont tendance à micro-manager leur équipe, ce qui entraîne la frustration des personnes qui travaillent dans ces équipes. Un processus de gouvernance trop restrictif pourrait être le signe d’un manque de confiance dans le fait que l’équipe fera ce qu’il faut. Les contrôles sont une bonne chose, mais dans les situations où ils entravent la création de valeur, les leaders doivent se poser la question de la confiance.
Le type de leaders qui soutiennent l’agilité s’intéresse à des indicateurs tels que :
[Source : EBM Metrics]
Contrairement aux leaders qui s’intéresseraient qu’à des indicateurs tels que la quantité de travail effectuée par l’équipe, l’utilisation des ressources et nombreux autres indicateurs qui ne correspondent pas à l’agilité.
Les leaders qui se concentrent sur leur équipe et travaillent avec elle pour améliorer les indicateurs de valeur constituent des équipes et des organisations solides qui sont bien positionnées pour apporter de la valeur à leurs clients.
Nous avons souffert de leaders qui se concentraient trop sur les résultats tels que le nombre de lignes de code produites, les articles de communication écrits, les billets publiés sur les médias sociaux, etc. car ceux-ci sont faciles à capturer.
Nous coachons ces leaders pour qu’ils aident leurs équipes à définir des résultats, ce n’est qu’alors que ces leaders auront plus de chances de constituer des équipes autogérées. Ces leaders co-créent des objectifs avec leurs équipes et les aident à atteindre ces objectifs. Il peut s’agir, par exemple, d’améliorer le Net Promoter Score de 20 % ou d’améliorer la fidélisation des clients de 30 % d’une année sur l’autre. Une fois les objectifs fixés, les leaders doivent permettre à leurs équipes de trouver des idées qui pourraient les aider à atteindre ces objectifs et à mesurer leurs progrès.
Une organisation agile est une organisation dans laquelle chaque leader est un coach, c’est-à-dire qu’il aide les membres de son équipe à être de meilleures versions d’eux-mêmes. Ces leaders sont des cheerleaders pour leur équipe, ils n’entravent pas le travail et ils déploient de l’autonomie, de la maîtrise et de la détermination pour motiver leur équipe. Ces leaders délèguent autant que possible à leur équipe et « révèlent plutôt que résolvent » lorsque leurs équipes sont confrontées à des défis.
Notre travail a vu beaucoup trop d’organisations commencer leur parcours agile en formant leurs équipes alors que les leaders sont généralement trop occupés pour se former. Les leaders ne peuvent pas mener des efforts de changement dont ils ne font pas eux-mêmes partie.
Praticien agile et agnostique ainsi qu’un formateur professionnel Scrum avec Scrum.org
Le paysage concurrentiel actuel est en évolution rapide, caractérisé par l’arrivée de nouveaux acteurs dans des domaines d’activité établis, l’évolution des besoins des utilisateurs et l’introduction de nouvelles technologies à un rythme très rapide. La plupart des organisations ne peuvent suivre ce rythme et l’agilité organisationnelle est une capacité essentielle pour votre réussite.
Les leaders sont souvent désireux de comprendre l’impact de l’adoption de méthodes de travail agiles et, dans cet article, nous explorons 5 indicateurs clés qui aident les leaders à suivre l’amélioration des équipes et des produits dans l’ensemble de l’organisation. Ces métriques sont d’excellents indicateurs pour ouvrir la voie à l’innovation, à la résilience et à une croissance soutenue.
Une mesure de la fréquence à laquelle une organisation délivre des mises à jour de son ou ses produits est l’un des principaux indicateurs du développement de ses capacités d’agilité business. Les approches agiles telles que Scrum aident les organisations à livrer fréquemment de la valeur aux utilisateurs. Avant même qu’un produit ne soit construit, la valeur qu’il apporte à ses utilisateurs cibles est estimée et les organisations valident les hypothèses lorsque le produit est finalement mis à la disposition du client. Une organisation dont la fréquence de sortie est plus rapide recueille potentiellement plus fréquemment les commentaires de ses utilisateurs.
L’organisation doit s’efforcer d’augmenter la fréquence de mise sur le marché de ses produits au fil du temps. Une fréquence de sortie plus élevée améliore l’agilité de l’entreprise en permettant une innovation plus rapide, une réactivité aux besoins des clients et une adaptabilité aux changements du marché.
Il y a un certain nombre de facteurs que nous pourrions prendre en compte pour augmenter la fréquence de sortie de ses produits :
Investissement dans les capacités d’intégration et de déploiement continus.
Les équipes produit sont responsables de la livraison de produits utilisables à leurs clients et les incidents, lorsqu’ils se produisent, nuisent à la convivialité de vos produits. Les incidents font référence aux temps d’arrêt du produit, aux pannes du produit et aux défauts non détectés du produit, entre autres. Les leaders doivent encourager et soutenir l’équipe produit afin de réduire le nombre d’incidents rencontrés par les utilisateurs par période. Les entreprises doivent investir dans des capacités techniques qui permettent de capturer automatiquement ce type de problèmes à partir des relevés d’incidents et, en outre, de fournir aux utilisateurs un moyen de signaler ces problèmes.
Les entreprises gagnent beaucoup de bonne volonté de la part de leurs clients si ces problèmes peuvent être détectés et corrigés avant qu’ils ne soient visibles par les utilisateurs. Pour s’assurer qu’un produit conserve sa valeur pour ses utilisateurs, le nombre d’incidents par période doit avoir tendance à diminuer au fil du temps.
Voici quelques facteurs qui pourraient contribuer à réduire le nombre d’incidents par période :
Le développement de produit est complexe. Complexe implique qu’il n’y a pas de relation directe entre la cause et l’action [Lire : Modèle Cynéfin]. En termes plus simples, il n’y a aucune garantie que les hypothèses que l’équipe produit fera lors de la construction du produit correspondront à la réalité. Par conséquent, plus tôt une organisation peut mettre en œuvre ses idées et mettre le produit entre les mains d’un utilisateur, plus tôt la valeur supposée du produit peut être validée.
La construction d’un produit est coûteuse et jusqu’à ce qu’un produit soit mis à la disposition de ses utilisateurs, le budget dépensé jusque-là pourrait être assimilé à un « stock d’invendus » comme dans le cas d’une entreprise traditionnelle.
Le délai d’exécution est le temps écoulé entre l’idée et le produit fonctionnel entre les mains du client.
Souvent, l’équipe produit trouve qu’il est plus facile de mesurer le temps de cycle, c’est-à-dire le temps écoulé entre le moment où une tâche est en cours et le produit entre les mains du client. Le temps de cycle peut être mesuré à la place du délai d’exécution, mais en fin de compte, l’équipe produit doit améliorer son système de management du backlog (l’arriéré de produit) pour calculer le délai d’exécution.
Il convient de souligner que l’effort visant à augmenter la fréquence de livraison devrait réduire le délai d’exécution. Cependant, la mesure et la visualisation du délai d’exécution apportent une valeur ajoutée à part entière.
Les facteurs qui améliorent les délais sont les suivants :
Dans notre travail avec les clients, nous avons observé que les leaders n’accordent pas suffisamment d’attention à une mesure très importante : Le niveau de satisfaction des personnes qui font réellement le travail. Il semble que les leaders supposent au fil du temps que les employés qui ne montrent pas de signes visibles d’insatisfaction doivent certainement être heureux et notre travail a montré que ce n’est certainement pas le cas
Les employés qui ne sont pas satisfaits au travail et ont des niveaux de moral en baisse ne sont pas en mesure de fournir des produits de valeur que les utilisateurs adorent. Lors d’un récent engagement de transformation de l’organisation où nous avons remarqué que le moral des employés était en baisse, les leaders avaient demandé à l’équipe d’augmenter la fréquence des livraisons et de réduire le temps de cycle, mais les équipes ne pouvaient pas améliorer ces mesures sans l’adhésion des leaders à la prise de certaines décisions qui impliquaient d’investir dans l’automatisation et de restructurer les équipes. Les leaders ont également supposé qu’il était facile pour les équipes de s’améliorer. La seule façon d’obtenir l’engagement des leaders a été de mener une enquête sur la satisfaction des employés, qui a donné des résultats négatifs.
Nous avons pu cocréer un certain nombre d’initiatives avec les équipes produit, notamment :
Des méthodes de travail qui ont donné de l’autonomie et du sens aux équipes.Les employés engagés et heureux sont plus susceptibles d’accepter le changement, d’apporter des idées innovantes et de collaborer efficacement, alimentant ainsi l’agilité et le succès de votre organisation.
Il faut beaucoup de travail pour créer des produits qui apportent continuellement de la valeur à leurs utilisateurs et les organisations capables de créer des produits de valeur peuvent s’attendre à ce que la satisfaction des clients s’améliore au fil du temps.
Les 4 indicateurs : Fréquence de livraison, Incidents par période, Délai d’exécution et Satisfaction des employés, contribuent tous à améliorer la satisfaction client.
Il existe un certain nombre de techniques qui ont été utilisées pour mesurer la satisfaction des clients, notamment le Net Promoter Score (NPS) et le taux d’attrition des clients.
L’équipe produit peut également envisager le déploiement de données de télémétrie qui fournissent des informations sur les comportements des utilisateurs au sein du produit.
Les mesures de satisfaction client fournissent des informations précieuses sur la façon dont le produit répond aux attentes des clients et va même plus loin. En écoutant activement vos clients et en adaptant vos produits, services et expériences en conséquence, votre équipe produit favorise la fidélité, établit des relations durables et garde une longueur d’avance sur un marché concurrentiel.
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.
Je continue à travailler avec des gens qui ont du mal avec leur approche agile. Ils me disent que leur estimation relative ne fonctionne pas pour eux. Ils continuent de repousser des items, d’un sprint à l’autre. Ils ont repoussé certains items pendant six mois ou plus. Les gens se sentent démoralisés. Et les Scrum Masters ou les managers de projet agiles n’ont aucune idée de la façon de remédier à la situation.
C’est alors que je leur recommande d’utiliser les métriques de flux au lieu d’une de leurs mesures plus traditionnelles. Parce que leurs mesures actuelles n’aident pas.
Les métriques de flux sont l’unique « secret » qui peut améliorer l’agilité dans n’importe quelle approche. Ces métriques exposent les principes qui sous-tendent l’agilité. Lorsque les équipes mesurent ces 4 métriques, elles peuvent voir leur réalité et décider quoi faire pour créer un meilleur environnement. Et, comme pour la plupart des principes, il y a une petite différence dans la façon dont ils sont importants pour les équipes et les managers.
Tout d’abord, voyons quelles sont les métriques de flux.
4 Métriques de flux
Bien que les métriques de flux soient indépendantes, elles créent des interactions et des dynamiques qui affectent le fonctionnement d’une équipe ou d’un manager. Commençons par une équipe.
Imaginez une équipe qui termine régulièrement un item de travail chaque semaine. C’est leur débit régulier. Maintenant, quelqu’un pense qu’il a besoin d’en faire « plus ». Peut-être que quelque chose a changé sur le marché ou que la direction n’est pas satisfaite du rendement de l’équipe. Ou peut-être qu’un concurrent gagne du terrain. Quoi qu’il en soit, l’organisation en veut « plus ».
Une personne bien intentionnée demande à l’équipe de commencer un item de plus cette semaine et de le terminer. Cela augmente le WIP de l’équipe. Cependant, à moins que l’équipe ne change quelque chose dans sa façon de travailler, elle n’augmente pas son débit juste parce qu’elle a commencé un item supplémentaire.
En fait, leur débit a diminué parce qu’ils travaillent sur deux éléments en même temps et qu’ils n’ont terminé aucun d’entre eux. Pire, leur temps de cycle augmente. Et maintenant, ils ont deux items de travail plus anciens, ce qui augmente le vieillissement de tous les items.
La demande de travail augmente, tout cela parce que l’équipe n’en a pas terminé « assez ».
C’est une boucle de rétroaction qui se renforce. Au fur et à mesure que l’encours augmente, le temps de cycle augmente. L’équipe a un débit plus faible, ce qui conduit à des items plus anciens. Tout cela augmente leurs travaux en cours.
Nous tournons en rond, créant un environnement de pire en pire pour l’équipe.
Si vous avez déjà vu une équipe « repousser » des histoires utilisateur d’un sprint à l’autre, vous avez vu cette dynamique. C’est pourquoi l’estimation relative et la vitesse ne sont pas utiles, mais la mesure du temps de cycle fonctionne.
La bonne nouvelle, c’est que l’équipe peut intervenir n’importe où dans ce cycle et apporter des améliorations.
Voici les questions que l’équipe peut poser :
J
‘ai tendance à commencer par l’une ou l’autre des deux premières questions, car elles se concentrent sur une chose que l’équipe peut terminer. Lorsque l’équipe réduit son travail en cours à un seul élément, elle doit modifier sa façon de travailler.
Ensuite, plus le WIP est faible, plus le débit est élevé, plus le temps de cycle est faible et plus le nombre d’anciens éléments est réduit.
C’est la même boucle de rétroaction, mais d’une manière qui soutient l’équipe.
Est-ce que « un » item est toujours le bon nombre pour les travaux en cours ? Non, je recommande à l’équipe de commencer par diviser par deux le nombre de personnes dans l’équipe (pour déterminer le WIP optimal de l’équipe). Si vous avez un nombre impair de personnes, arrondissez en dessous. Donc, si vous avez cinq personnes, utilisez « deux » comme travail en cours maximal.
Mais votre équipe peut commencer par des changements au sein de l’équipe pour réduire le temps de cycle et augmenter le rendement. Vous pouvez commencer n’importe où car c’est une boucle de rétroaction.
Les managers travaillent différemment. Les métriques ne changent pas, mais les interventions du management sont différentes.
Les métriques de flux interagissent de la même manière pour les managers que pour les équipes. Cependant, les managers ne produisent pas de fonctionnalités. Au lieu de cela, ils prennent des décisions. C’est pourquoi les idées de « Pourquoi minimiser le temps de décision de la direction/ Why Minimize Management Decision Time” sont si importantes.
Plus les managers ont de décisions non finalisées (vieillissement des décisions), plus ils ont de décisions en cours (leur WIP). Plus l’encours WIP d’un responsable est élevé, plus le temps de cycle est long et plus le débit est faible. Cela signifie que les gens ne savent pas quoi faire et décident par eux-mêmes. Les gens ne peuvent plus attendre une décision du management.
Bien que les questions soient un peu différentes, les managers peuvent utiliser la boucle de rétroaction pour créer une boucle qui fonctionne pour eux, et non contre eux.
Lorsque les équipes et les responsables voient clairement leurs travaux en cours/WIP, leur temps de cycle, leur débit et leur vieillissement, ils peuvent décider de ce qu’ils souhaitent modifier.
Les métriques de flux sont importantes car elles permettent aux équipes et aux responsables de voir et de gérer leur façon de travailler.
Cette lettre d’information aborde les sujets abordés dans les livres :
Une équipe autonome et autogérée s’épanouit lorsque les liens hiérarchiques sont relégués au second plan, ce qui permet aux responsabilités Scrum de guider les méthodes de travail. Bien que les hiérarchies organisationnelles persistent, en particulier lors de la formation des équipes Scrum, il est crucial de discuter des privilèges et de leur impact sur la capacité d’une équipe à s’auto-gérer.
Cette forme explicite de privilège survient lorsqu’une équipe Scrum est composée d’employés ayant différents niveaux d’ancienneté. Les cadres supérieurs exercent une influence, prenant parfois des décisions unilatérales qui affectent l’ensemble de l’équipe. Par exemple, un responsable hiérarchique, également développeur au sein de l’équipe Scrum, pourrait choisir d’annuler une rétrospective de Sprint sans consulter les autres membres de l’équipe.
Accordé aux personnes expérimentées dans le domaine ou les compétences requises. Ce privilège peut conduire à une prise de décision rapide par les développeurs seniors et les responsables techniques, ce qui peut étouffer la contribution des membres moins expérimentés de l’équipe. Bien que des décisions rapides puissent être nécessaires dans certaines situations, il est essentiel d’assurer l’inclusivité.
Dans les équipes Scrum géographiquement distribuées, les nuances culturelles peuvent créer une dynamique de privilège. Les membres de l’équipe issus de cultures plus expressives peuvent involontairement dominer les discussions, ignorant les autres moins enclins aux confrontations. La reconnaissance et l’atténuation de ce privilège culturel favorisent un environnement véritablement inclusif et collaboratif.
Ces privilèges conduisent souvent quelques membres de l’équipe à prendre des décisions pour l’ensemble de l’équipe Scrum, s’écartant ainsi de l’essence de l’auto-gestion.
Reconnaître les privilèges au sein de l’équipe : Animez une conversation pour discuter de toutes les formes de privilèges au sein de l’équipe. La sensibilisation est la première étape pour faire prendre conscience aux membres de l’équipe de leurs privilèges et leur impact sur la collaboration et l’auto-gestion.
Lors d’une session de planification de sprint avec un nombre limité de membres de l’équipe, le Product Owner, en raison de son rang supérieur, a proposé d’annuler la réunion sans consulter tous les membres de l’équipe. Reconnaissant ce privilège, le Scrum Master est intervenu, ce qui a déclenché une discussion qui a mené à un processus décisionnel plus inclusif.
La prise en compte de la dynamique des privilèges garantit que les équipes Scrum incarnent les principes d’autonomie, de collaboration et d’auto-gestion, ce qui conduit au développement d’équipes hautement efficaces capables d’apporter de la valeur à leurs parties prenantes.
Coach Agile Principal et Formateur Principal at Valuehut, un cabinet de conseil en coaching et formation agile, qui aide les organisations à explorer les méthodes de travail agiles. Sam a beaucoup d’expérience dans le soutien aux dirigeants et à leurs équipes en matière d’agilité d’entreprise avec un objectif ambitieux :Aider les organisations à développer un état d’esprit agile nécessaire pour continuer à garder une longueur d’avance sur la concurrence et les marchés.
Le test d’acceptation par l’utilisateur (User Acceptance Testing / UAT) est une pratique de développement de produits très populaire dans les méthodes traditionnelles de développement de produits. Ces méthodologies traditionnelles sont caractérisées par de longues phases de développement et de déploiement du produit dans un environnement UAT, suivies d’une longue période de test dans l’environnement UAT.
La question est de savoir si l’UAT continuera d’être une pratique pertinente pour les équipes agiles et leurs parties prenantes, en partant du principe que les organisations adoptent des méthodes de travail agiles pour être en mesure de créer de meilleurs produits plus rapidement. La phase d’UAT est une pratique qui est souvent mandatée par les cadres supérieurs au sein de l’organisation et parce que la phase d’UAT ne peut pas s’intégrer dans le Sprint (dans le cas des équipes Scrum), ces équipes contournent l’« obstacle » en modifiant la définition de Done pour leur produit afin d’exclure l’UAT. En d’autres termes, l’équipe Scrum a tendance à modifier son livrable de Sprint pour en faire un produit dont le développement est terminé mais qui n’a pas encore été testé par les utilisateurs et/ou les parties prenantes.
Pour le scénario décrit ci-dessus, quelle que soit la vitesse à laquelle l’équipe Scrum travaille pour amener ses éléments de travail à l’état de développement terminé, l’équipe Scrum crée effectivement un lot de travail qui n’est pas délivré en production avant un certain temps. La phase UAT peut durer de 4 semaines à 3 mois ; et nous pensons que la phase UAT ne rend pas service à tous les efforts visant à renforcer les capacités d’agilité de l’organisation.
Voici quelques exemples de complexité supplémentaire introduite par une pratique distincte de l’UAT et question à se poser :
Chez Valuehut, nous aidons nos clients à intégrer toutes les formes de tests au sein du Sprint (y compris les tests d’acceptation par les utilisateurs) ; La promesse de Scrum est d’aider les équipes à fournir des produits utilisables et précieux à leurs utilisateurs le plus rapidement possible et en renforçant les capacités au sein de l’équipe pour effectuer des tests d’acceptation par les utilisateurs dans le cadre du Sprint. L’équipe a alors plus de chances de fournir un produit précieux et disponible à ses utilisateurs / parties prenantes dans chaque sprint.
Les équipes Scrum qui n’ont pas accès à un environnement de test qui est une représentation de l’environnement de production disposent généralement d’un environnement UAT, qui est partagé par de nombreuses équipes. La non-représentativité peut faire référence à la taille et à la capacité de l’environnement ou à un environnement qui n’est pas configuré correctement avec toutes les applications en amont et en aval.
Pour résoudre ces problèmes, l’équipe doit argumenter en permanence pour avoir un environnement qui représente l’environnement de production. Rendre transparentes pour la direction les implications en termes de coûts qui pourraient être des opportunités perdues en raison de délais de livraison allongés.
Souvent, les utilisateurs professionnels qui sont censés exécuter le test d’acceptation utilisateur ont créé un ensemble de scénarios et de cas de test qui n’ont pas été partagés avec les développeurs.
Dans ce cas, l’équipe Scrum devrait plaider pour que ces scénarios utilisateur soient partagés avec l’équipe Scrum en s’associant aux utilisateurs professionnels et en utilisant le coût de la reprise pour répondre à ces scénarios.
Dans cette situation, l’entreprise n’est généralement pas confortable avec l’idée de charger des données de test représentatives dans les environnements de test pour un certain nombre de raisons, telles qu’un environnement de test inadapté ou un problème de confidentialité des données.
Les développeurs doivent s’efforcer d’anonymiser les données et de créer des jeux de test qui permettent à l’équipe Scrum d’accéder de manière cohérente à des données de test représentatives.
Il convient de noter que l’élimination de la phase d’UAT prend du temps et nécessite que les équipes Produit s’associent aux leaders de l’entreprise sur une longue période de temps, en effectuant de petites expériences à chaque fois jusqu’à ce que la phase d’UAT soit rendue redondante. La seule façon de rendre la phase d’UAT redondante est de rassembler suffisamment de preuves empiriques qu’aucun défaut n’est trouvé dans cette phase d’UAT ; Cela permet d’établir la confiance avec les parties prenantes au fil du temps, et l’équipe Scrum doit fournir aux parties prenantes la preuve des tests exécutés dans chaque sprint.
La capacité d’agilité organisationnelle aide les organisations à être efficaces (en créant les bons produits, par exemple un produit que les clients aiment utiliser) et efficientes (en construisant les bons produits, par exemple en réduisant les délais de mise sur le marché) ; Par conséquent :
Les organisations qui veulent être compétitives dans un monde complexe doivent repenser des pratiques telles que la phase d’acceptation par les utilisateurs, qui ralentissent le temps total nécessaire pour mettre de nouveaux produits ou fonctionnalités entre les mains de leurs clients.
Praticien agile et agnostique ainsi qu’un formateur professionnel Scrum avec Scrum.org
La loi de Little porte le nom de son inventeur, John Little, qui a établi la théorie des files d’attente dans les années 1950s.
Au départ, la loi avait pour objectif de fournir une formule très simple pour juger de l’efficacité d’un système de gestion de file d’attente.
En 1961, Little a énoncé son théorème :
Le nombre de clients dans une file d’attente est égal au taux d’arrivée moyen des clients multiplié par le temps nécessaire pour les traiter.
Puis, cette loi fut souvent utilisée dans les approches Lean pour réduire les délais. Elle permet de calculer le temps moyen passé dans un système de production entre le début et la fin d’une tâche. L’objectif est bien sûr d’augmenter la capacité de production.
De nos jours, la loi de Little est utilisée dans les approches Agile, en particulier avec Kanban, car elle établit un lien très clair entre le WIP (Work In Progress – Travail en cours), le Lead Time LT (temps moyen pour exécuter une tâche) et le Taux de production T (le débit).
Cette formule est souvent exprimée ainsi :
WIP = T x LT
ou encore
LT = WIP / T
Toute augmentation des travaux en cours WIP augmente automatiquement les délais.
Dans les faits, certaines entreprises ont tendance à faire l’inverse. Elles augmentent les travaux en cours dans l’espoir d’augmenter la production et il en résulte souvent un total désastre en ce qui concerne le respect des délais.
De même, si une entreprise a du mal à exécuter tous les projets en cours, en lancer de nouveau a peu sinon aucune chance d’améliorer la situation. Or, c’est encore trop souvent ce qui se produit.
Nous pouvons utiliser cette loi pour mieux comprendre pourquoi nous avons de meilleures chances de les mener à bien en manageant plus efficacement les projets en cours plutôt qu’en lançant d’autres projets.
Cela correspond comme je l’ai mentionné précédemment aux objectifs recherchés par le management des flux avec Kanban dans les projets Agiles.
Lancer trop de projets engorge les processus, surcharge les horaires de travail des développeurs et allonge considérablement le temps de réalisation.
Prenez un exemple :
Avec l’approche « séquentielle », vous pouvez donc commencer à récolter les bénéfices de votre premier projet 2 ans plus tôt qu’avec le lancement de tous les projets en parallèle et les avantages du second une année plus tôt.
Ces bénéfices peuvent être ce qui fera ou défera le succès de votre organisation tant vos capacités d’auto-financement sont de plus en plus importantes.
En fait, si le premier projet est délivré après 12 mois, il vous faudra supporter sa mise en production, corriger les erreurs, écouter les retours des utilisateurs, effectuer quelques ajustements impératifs…
Même avec un plan de mise en production accompagné de ressources additionnelles dédiées au support en sus des développeurs, il y aura probablement des impacts non négligeables sur leur charge de travail.
Donc, en réalité, je ne pense pas que vous terminerez systématiquement le second projet 24 mois après la date de début. Et je suis quasiment certain que le troisième projet ne sera pas fini dans la période cible de 3 ans.
Mais, en revanche, il est certain que vous obtiendrez des bénéfices des projets numéros 1 et 2 beaucoup plus tôt que si vous lancez les 3 en parallèle.
Il est clair que plus vos employés ont de projets sur lesquels ils travaillent en parallèle, plus les délais d’exécution de chacun de ces projets seront longs.
Le temps de passage d’un projet à l’autre en cours de journée ou de semaine, le switching time, est à ajouter à vos délais. En effet, cela consomme du temps que de poser votre crayon sur un sujet, vous remettre dans le contexte de votre autre tâche ou projet, puis être à nouveau pleinement productif sur celui-ci. C’est l’une des raisons pour lesquelles le multi-tâches est fortement déconseillé en approche Agile où toute l’équipe doit travailler ensemble.
En limitant le nombre de projets en cours, les ressources nécessaires sont disponibles et davantage focalisées. Le résultat est un achèvement du projet bien plus tôt.
La loi de Little est un excellent principe à suivre dans le management des portefeuilles de projets (PPM) car elle vous permet de conserver une vue d’ensemble tout en optimisant la mise en œuvre opérationnelle.
Il vous reste cependant (encore et toujours) à bien travailler les business cases pour être certains de choisir le bon ordre de séquencement des projets !
Que l’approche de développement soit Agile ou prédictive, il est critique dans chaque projet sélectionné de bien travailler sur la liste des fonctionnalités souhaitées et les prioriser en fonction des bénéfices attendus de chacune d’entre elles.
C’est en Agile en grande partie la responsabilité du Product Owner.
Et c’est, selon moi, aussi là qu’un intérêt majeur des approches Agiles va se matérialiser : Savoir quand s’arrêter !
En effet, en plus de livrer au plus tôt les fonctionnalités les plus critiques, en approche Agile vous pouvez et devez décider quand dire stop.
En arrêtant votre projet dès que les bénéfices additionnels ne justifient plus de mobiliser les ressources allouées, vous allez les libérer pour le projet suivant qui apportera davantage de bénéfices à l’entreprise.
Il y a là bien sûr un fort risque de ne jamais terminer un projet à 100% par rapport à son business case originel. Mais ceci est-il réellement un problème ?
J’ai vu dans tous les projets que j’ai suivi des fonctionnalités très prometteuses sur le papier n’être que faiblement voire jamais utilisées alors qu’elles nous avaient coûté un bras. C’était rarement dû à une pauvre qualité du livrable. Il s’agissait plutôt de besoins qui avaient évolués pendant la durée de développement du projet, ou bien dus à des changements dans les processus ou les organisations qui étaient parfois encore plus « Agiles » que nos développeurs.
DantotsuPM.com 