Savez-vous ce qu’est un registre de « Dette Technique » et comment bien l’utiliser dans les méthodes itératives #Agile ?

Le 7 février 20197 février 2019 par mopertodans agileLaisser un commentaire

« Dettes et mensonges sont ordinairement ensemble ralliés » Rabelais dans Pantagruel.

Using a « Technical Debt Register » in Scrum

https://www.scrum.org/resources/blog/using-technical-debt-register-scrum par Ian Mitchell

En vieillissant, je me métamorphose en l’un de ces types nostalgiques et ennuyeux qui vit trop dans le passé. Les choses étaient mieux avant, mon enfant. Nous avions des standards et il y avait moins de « sur-simplification ».

Mais parfois au crépuscule, comme je me lève de mon fauteuil à bascule sous le porche et me penche en avant pour soulager mon dos, je reconnais qu’il y a une chose qui est en réalité meilleure maintenant qu’au début des années 2000 : De nos jours, un homme peut parler de la « dette technique » sans que les gens le prennent pour un fou.

La dette technique peut être définie comme les conséquences à long terme de faibles décisions de conception. À l’origine décrit comme une métaphore par la Ward Cunningham, à peu près tout le monde accepte maintenant que la dette technique est un risque réel qui peut réellement être encouru. Cette identification est bonne. Critiquer Java et en damner les conséquences n’est pas vraiment « Agile », c’est juste jouer au cow-boy. Mais la vérité est que pendant des années, cela n’a pas été compris, pas avant que les dettes de certains imbéciles soient si importantes qu’elles ne puissent perdurer.

Cela vaut cependant la peine de garder à l’esprit que pas tous les défauts et bugs ne constituent de la dette technique.

Écopez un peu de votre dette avant qu’elle ne vous noie.

C’est parce qu’ils ne reflètent pas toujours « des décisions de conception ». Ce sont souvent juste des erreurs, peu importe à quel point ils pourraient être irresponsables ou indignes. Ainsi quand une décision ne met pas directement en péril la qualité de produit, ce n’est pas de la dette technique. Une équipe peut souhaiter un nouvel environnement ou un module d’extension, mais ne pas les fournir n’est pas de la » dette technique », puisque cela ne met pas en danger la qualité du produit lui-même. Cela pourrait très bien réduire la vitesse de développement, parce qu’ils doivent boitiller en utilisant une vieille plate-forme de développement, mais c’est un problème différent.

Dans Scrum, l’attente consiste en ce qu’une définition de DONE (fait) devrait être suffisamment robuste pour que des niveaux ingérables de dette ne puissent pas s’accumuler. De là, si on sait que la dette technique va augmenter, la définition de DONE devrait être revisitée. Il est essentiel de découvrir pourquoi la dette est encourue et comment cela peut être évité.

Il y a certain nombre d’autres contrôles qui peuvent être utilisés pour limiter la dette.

Par exemple, une équipe devrait tenir compte du « refactoring » (et bien d’autres tâches) en décidant de combien de travail ils peuvent embarquer dans un Arriéré de Sprint sans mettre en péril la qualité à long terme. Mais en dehors de ces contrôles et recherches d’équilibre, il n’y a aucune prescription sur comment la dette technique devrait être traitée une fois que vous l’avez. Ce n’est pas une inadvertance, puisque Scrum est délibérément aussi non-normative que possible. C’est une structure de travail qui laissent aux équipes la décision de comment elles la mettent en œuvre.

Notez cependant que mettre en œuvre « des sprints spéciaux » pour nettoyer la dette technique n’est pas une option. Des sprints techniques de dettes, aussi mentionnés comme des sprints de solidification ou renforcement, sont essentiellement un anti-modèle. Chaque Sprint doit apporter un incrément de valeur véritable. C’est pourquoi la Définition de DONE est le rempart primaire contre l’accroissement de la dette en premier lieu.

Ce que font certaines équipes est de maintenir un registre de dettes techniques

Dans ce registre les décisions de conception qui mènent à de la dette peuvent être rationalisées. Vous pouvez penser à ce registre comme un registre RAID (Risques, Assomptions, Issues & problèmes, et Dépendances) qui est sous le contrôle de l’équipe. L’équipe y détaille les conséquences techniques de décisions prises de manières opportunes sur la qualité de mise en œuvre du produit, souvent en termes de probabilité, d’impact et de remédiations envisagées. Il peut être possible de recommander de l’adresser pendant un Sprint, si l’équipe a une compréhension suffisante de l’Arriéré de Produit. Suppositions et dépendances peuvent aussi entrer dans le registre et bien sûr quelques risques peuvent finalement transformer en douloureux problèmes.

Un registre technique de dettes peut aider à informer des équipes de comment la dette encourue devrait être gérée. Ils peuvent prendre des décisions réfléchies et informées sur quand vraiment ajouter de la dette et quand au contraire la rembourser. L’utilisation d’un tel registre ne fait pas partie de Scrum, mais néanmoins cette technique peut aider une équipe à prendre en main la dette technique qu’ils décident d’accepter. Parfois, par exemple, la dette technique peut être réglée en mettant en œuvre des histoires de l’arriéré de produit. Dans d’autres cas pas, et la dette doit alors être adressée séparément.

Que faire ?

Certains cas de dette peuvent devoir être exposés au Propriétaire de Produit pour leur prise en considération et d’autres pas. Dans les cas sévères, de la dette technique peut avoir été accumulée qui excède la valeur du projet lui-même, probablement même de multiples fois. Dans de tels cas extrêmes, l’approche la plus pragmatique peut être de tuer le projet et repartir de zéro. Inutile de le dire, cette variation de « échouer maintenant plutôt que plus tard » nécessite un courage extrême.

Une autre option quand on fait face à une dette technique substantielle est de la réduire graduellement, Sprint après Sprint. L’équipe peut devoir s’entendre avec le Propriétaire de Produit pour livrer quelque chose, à chaque itération, qui fournisse tout de même une valeur suffisante aux parties prenantes. Clairement ce n’est pas une excellente option. Elle peut se terminer en marchandages, où la magnitude et la propriété du problème de la dette ne sont pas reconnues ni rendues visibles des parties prenantes. La dette technique devient alors plus d’un cas de problème technique. Les parties affectées pourraient être encouragées à fermer les yeux tant qu’elles obtiennent quelque chose de valeur immédiate pour le business en retour, mais aucun de ceci n’est bon pour la franchise, la confiance ni la transparence.

Maintenant, bien qu’ayant comparé un registre technique de dettes à un registre RAID, je ne suggère pas qu’il doive prendre la forme « documentée » habituelle de celui-ci. Selon mon expérience, il est généralement meilleur d’utiliser un « Information Radiator ». Parfois, cela peut être aussi rudimentaire qu’une feuille de papier scotchée au dos de la chaise du ScrumMaster, mais je préfère proposer aux équipes d’utiliser un mur de cartes dédié à cette fin. Les statuts typiques sont : A faire, En cours, Fait et A escalader. Les articles sont Faits quand ils sont ou atténués ou acceptés.

Incidemment, cela marche aussi pour les registres RAID conventionnels au niveau du projet et du programme. L’escalade depuis un Registre de Dettes Techniques impliquerait sa promotion à un tel niveau. Les managers sont ainsi encouragés à prendre un intérêt actif dans ces registres et questionner tout problème non remonté qui semblent bloqué.

Cela peut être une excellente façon d’encourager le « gemba » chez les managers, où ils sortent du bureau, s’y promènent, mettent leurs liens hiérarchiques et filtres de côté et voient la réalité des choses par eux-mêmes.

Pour aller plus loin, relisez ces précédents billets sur ce sujet

Comment rester un manager de projet pertinent voire recherché dans le monde actuel ?

Le 4 février 201928 janvier 2019 par mopertodans agileLaisser un commentaire

S’adapter au monde numérique et disruptif ou bien disparaitre: Le quotidien des managers de projet…

Staying relevant as a Project Manager in today’s world

http://www.virtualprojectconsulting.com/staying-relevant-as-a-pm/ par Derek Smith

Dans le monde numérique et disruptif actuel, les cadres et organisations font face à de féroces défis compétitifs qui exigent qu’ils s’adaptent continuellement, ou bien affrontent les conséquences de ne pas le faire et la possibilité de disparaitre totalement. Il en va de même pour les managers de projet. Ils/Elles doivent se tenir au courant ce qui change avec les méthodes Agiles et dans la philosophie du management de projet pour rester pertinents et employables.

Pratiques Agiles et Lean

Des pratiques flexibles Agiles et Lean, comme Scrum et Kanban qui étaient autre fois un domaine réservé aux développeurs de logiciels, sont idéalement positionnées pour générer le succès dans le business. Elles font des incursions significatives à l’extérieur du département informatique et trouvent l’acceptation et l’appui des dirigeants exécutifs. Les organisations ont besoin de sentir rapidement venir les changements externes et internes et de s’y adapter pour livrer des résultats efficaces et rentables, sans perdre de vue le fait que la gouvernance d’ensemble est toujours requise.

La recherche du succès commence aussi par choisir la bonne approche pour délivrer les projets. Certaines caractéristiques spécifiques des projets et des besoins organisationnels devraient former les bases du choix de l’approche la meilleure.

Alors que chacun saute sur le train en marche pour capitaliser sur la formation et l’adoption, et avec tant de choix quand on parle des approches, il peut être intimidant d’essayer de suivre les avancées sur comment ces pratiques se développent et lesquelles choisir. PMI a produit une série de rapports sur le leadership. Notons que les 6 rapports sont liés à atteindre une plus grande agilité.

Les rapports couvrent des sujets comme se concentrer sur le client, provoquer des retours fréquentes, choisir la bonne approche et transformer l’organisation en se concentrant sur les personnes et surveillant les progrès. Développer la collaboration entre des branches différentes du business, changer la culture et évaluer les besoins transverses aux entités fonctionnelles sont d’autres aspects primordiaux à considérer pour atteindre une agilité organisationnelle plus élevée.

Avancement de carrière

Du point de vue de leur carrière, les managers de projet doivent continuer à être au fait des avancées pour rester recherchés et gagner des salaires convenables. PMI Pulse of the Profession® indique que les parties prenantes font le forcing pour adopter des pratiques agiles. Les organisations qui sont agiles et répondent rapidement à la dynamique des marchés, récoltent plus de bénéfices de leurs projets que celles qui ne le sont pas — 75% contre 56%, selon la recherche.

Il est pour cette raison que le PMBOK ® le Guide –Sixième Édition s’est enrichi de pratiques agiles et que le PMI® s’est associé avec Agile Alliance® pour créer le nouveau Agile Practice Guide.

La certification PMI-ACP® est actuellement celle qui connait la croissance la plus rapide au PMI et couvre beaucoup d’approches Agile comme Scrum, Kanban, Lean, la programmation extrême (XP) et le test-driven development (TDD).

“PMI,” the PMI logo, “PMP,” “PMBOK,” “PM Network,” “Project Management Institute” and “Pulse of the Profession” are registered marks of Project Management Institute, Inc.

PRINCE2 Agile pour les manager de projet et organisations PRINCE2®

Le 25 janvier 201919 janvier 2019 par mopertodans agile, outils et méthodesLaisser un commentaire

Agile signifie accepter que votre projet ne livrera pas nécessairement tout qui a été spécifié au départ et que, en effet, les utilisateurs n’ont pas nécessairement besoin de tout ce qu’ils ont spécifié.

PRINCE2 Agile for PRINCE2® practitioners

https://www.axelos.com/news/blogs/october-2018/prince2-agile-for-prince2-practitioners par Julia Gosse

A quels défis PRINCE2^® les praticiens et leurs employeurs font-ils face avec le concept de livraison de projet Agile ?

Le plus grand défi consiste en ce que le terme « Agile” est souvent mal compris : les gens pourraient faire des raccourcis comme « juste plus vite »; ils pourraient avoir entendu dire que c’est seulement pour les projets informatiques, qu’il relève seulement de Scrum ou que leurs contraintes légales les empêchent d’utiliser.

L’approche Agile

Les projets agiles aboutissent souvent à une livraison plus rapide mais Agile est un état d’esprit. Cela signifie accepter que votre projet ne livrera pas nécessairement tout qui a été spécifié au départ et que, en effet, les utilisateurs n’ont pas nécessairement besoin de tout ce qu’ils ont spécifié.

Quand vos délais sont figés vous devez vous concentrer sur quelles sont les réelles priorités. Se précipiter pour tout délivrer peut diluer le résultat et réduire le niveau de qualité, quelque chose qui reviendra vous hanter plus tard. Un projet Agile préfère ne pas livrer une chose si elle n’est pas à la norme exigée, mais tout dans l’approche est conçu pour s’assurer que ce qui est livré apportera de la valeur au client.

Des approches de livraison Agiles sont de plus en plus utilisées avec beaucoup de succès dans les projets en dehors de l’informatique. J’ai récemment travaillé avec une société d’événementiel utilisant Agile pour planifier et organiser une grande conférence. C’était particulièrement utile pour ce projet qui avait une durée imposée et des coûts fixes.

Davantage d’organisations et praticiens expérimentés avec PRINCE2 gèrent bien cette approche et voient Agile comme un outil très utile. En conséquence, ils adoptent certaines approches comme la co-localisation de l’équipe de projet, l’utilisation d’interactions régulières et la collaboration avec clients et utilisateurs.

Le webinaire en replay de notre partenaire QRP

Pourquoi le travail avec PRINCE2 Agile est-il efficace dans une organisation PRINCE2 ?

1. Une langue et une approche communes

Vous avez déjà obtenu un niveau de contrôle et une terminologie que vous comprenez et les organisations PRINCE2 sont expertes pour adapter PRINCE2 à des projets différents.

2. Flexibilité avec les méthodes Agiles

Il y a beaucoup de saveurs différentes d’Agile et bien que Scrum soit probablement la plus populaire, ce n’est pas la seule approche de développement Agile. PRINCE2 n’a jamais été normatif dans la définition de comment vous livrez un projet et PRINCE2 Agile peut travailler avec une ou de nombreuses approches Agiles, y compris Scrum, Kanban et DevOps. Cela garantit que l’équipe de management de projet comprend comment s’interfacer avec l’approche de livraison Agile.

Prince2 est nativement tourné vers les approches Agiles

Il est important de comprendre que PRINCE2 Agile est toujours centré sur le management de projet et que l’équipe devra être formée dans l’approche (ou les approches) de livraison Agile qu’ils adoptent.

3. Avoir une perspective business

Dans PRINCE2 le manager exécutif représente les intérêts de l’organisation; appliquer ceci à l’environnement Agile est une approche gagnante car vous maintenez la perspective business. Cela assure que les utilisateurs ne se laissent pas emporter par leurs demandes et ce qui est livré répond aux exigences d’affaires. Cela résonne bien dans le monde Agile parce que la livraison de valeur est le principal déterminant pour donner la priorité à ce qui devrait être livré ensuite.

4. L’Agilomètre

Essentiellement c’est un outil d’évaluation de risque pour aider évaluer à quel point Agile est approprié pour un projet donné. Même dans un projet prédictif (en cascade) vous pouvez incorporer quelques éléments Agiles, donc l’Agilomètre permet aux organisations d’évaluer les implications de procéder ainsi.

Dans PRINCE2 Agile® Guidance, on trouve aussi une façon unique d’adresser les questions potentielles liées à l’introduction des méthodes agiles. Par exemple, des assomptions dérangeantes sur les besoins devant être spécifiés au début d’un projet, comment adresser la résistance à un plus grand niveau de collaboration et penser à de la formation ou des ateliers pour encourager l’acceptation d’Agile dans le management de projet.

Pourquoi les praticiens PRINCE2 devraient-ils embrasser Agile?

Les exigences et les attentes des utilisateurs dans un monde de haute technologie augmentent et les gens sont moins enclins à accepter des produits ou des systèmes périmés ou attendre pendant des mois et même des années pour les remplacer.

L’utilisation des apps sur les téléphones portables encouragent des retours et de nouvelles versions fréquentes. Nous devenons tous très habitués du style de livraison collaboratif, itératif et progressif qu’Agile favorise.

L’union des contrôles de management de projet de PRINCE2 avec la connaissance et des capacités Agiles facilite une plus grande adaptabilité aux changements sur les marchés et donne une capacité de répondre et de changer beaucoup plus rapidement.

Qu’est-ce que Agile Hybride en réalité ?

Le 18 janvier 201915 janvier 2019 par mopertodans agile, outils et méthodesLaisser un commentaire

“Nous ne sommes pas encore Agile, mais nous utilisons une approche hybride” ???

What is Hybrid Agile, Anyway?

https://www.agilealliance.org/what-is-hybrid-agile-anyway/ par Becky Hartman, Mike Griffiths, Johanna Rothman, Jesse Fewell, Betsy Kauffman, Stéphane Matola et Horia Slusanschi

Maintenant que le mouvement Agile s’est étendu à de plus grandes organisations dans davantage d’industries, nous voyons énormément de variation. Accordé, nous utilisons une grande variété de structures, techniques et méthodes utilisées, de XP à Scrum à Kanban à la Livraison Continue. Cependant, récemment nous entendons de plus en plus parler d’approches « Hybrides ».

Peut-être avez-vous entendu un dirigeant dire : “Nous ne sommes pas encore Agile, mais nous utilisons une approche hybride”.

Ou peut-être vous avez entendu un consultant déclarer fièrement “À moins que vous ne fassiez beaucoup de prototypage, vous êtes seulement Agile Hybride”. Et ensuite, lors d’une rencontre vous entendez une autre personne dire, “Oh, nous ne sommes pas hybrides, nous utilisons une approche mélangée”.

A travers toutes ces discussions, ce que les gens veulent dire en réalité peut devenir assez confus. Ceux parmi nous qui travaillent sur le prochain Guide de Pratique Agile ont aussi entendu ces points de vue et nous ajoutons qu’une section au guide concentrée sur ce sujet. Voici certains des modèles initiaux que nous voyons…

« Itératif » par rapport à « Incrémental » par rapport à « Agile »

Les cycles de vie des projets suivent un continuum, de prévisionnel (« plan driven ») à Agile. Pour nous aider à comprendre ce continuum, considérons deux des aspects clés de l’Agilité que sont “Livrer Tôt et Souvent” et “S’adapter au Changement”. Si nous devions les tracer sur un graphique bidimensionnel, nous obtiendrions quelque chose comme cela …

Sur le continuum d’approches, depuis prédictives (en bas à gauche) à Agiles (en haut à droite), il y a différents degrés de livraison (incrémentale) et degrés de changement (itératif). Les techniques qui réalisent à la fois de forts niveaux de livraison et de hauts degrés d’adaptabilité sont appelées « Agiles ».

« Mélangé » (Blended) versus « Hybride »

Mais c’est juste trop simpliste. Dans le monde réel, nous n’utilisons pas juste une approche. Nous combinons presque toujours plusieurs techniques différentes. Pour nous aider à comprendre les différentes combinaisons, nous avons posé quelques définitions de travail.

Mélangé Agile (« Blended Agile ») est la combinaison de deux ou plus des méthodes établies, techniques, ou structures Agiles.

En ajoutant un peu de Kanban et des limites de travail en cours (« Work In Progress ») à vos Sprints Scrum, vous obtenez une approche « Mélangée ». Ou peut-être voulez-vous « mélanger » un tableau de visualisation (« Information Radiator ») avec votre approche de livraison en continu. Pour beaucoup de praticiens Agiles, c’est facile à comprendre.

Nous combinons des techniques adaptatives-agressives connues pour être meilleurs dans ce que nous faisons :

Mélangé = Agile + Agile = Meilleur Agile

Mais en ce qui concerne le reste d’entre nous simples mortels ?
Et si nous ne sommes pas encore capables d’utiliser ces diverses techniques?
Et s’il y a contraintes ou demandes qui exigent que quelques éléments non-agiles se produisent ?

Et bien, dans ces cas, vous devriez considérer « l’Hybride »

L’Hybride Agile est la combinaison de méthodes Agiles avec d’autres techniques non-agiles.

Par exemple, un effort important pour détailler les exigences, suivi de sprints de livraison progressive serait une “Approche Hybride”. De même, le prototypage itératif fréquent d’un design, suivi d’une mise en œuvre prédictive avec un plan simple serait “une Approche Hybride”.

Ici, l’idée est de prendre une approche non-Agile et d’y injecter quelques techniques Agiles pour aborder une question ou une opportunité spécifique:

L’hybride = non-Agile + Agile = quelque chose entre les 2 qui a du sens

Quand devrions-nous utiliser des approches Hybrides ?

Comme toute autre chose dans le monde, il y a une bonne et une mauvaise raison de faire quelque chose. Pour être clair, la mauvaise raison de mélanger des techniques est de vouloir faire comme les autres. “Utiliser des techniques Agiles” n’est pas le but. Le but est de livrer le bon résultat business en utilisant les bonnes techniques.

Voici deux scénarios :

1. Hybride comme Adéquat en fonction du but

Pour les projets qui ont un profil de risque inférieur, utilise des approches prédictives pour minimiser les dépenses. Pour des projets de risque plus élevés, utilisez des techniques Itératives pour répéter des activités jusqu’à ce que les problèmes se révèlent et soient résolus. Pour des projets ayant besoin de livraisons agressives, des techniques Progressives livreront quelque chose plus tôt et assureront l’engagement du client. Finalement, pour naviguer dans des environnements complexes, des techniques Agiles peuvent avoir un fort coût initial aérien, mais pourraient le valoir pour les résultats d’ensemble. Chacune a sa propre force. Le mélange de celles-ci de la bonne façon peut mieux répondre à votre contexte que l’utilisation de seulement une d’entre elles.

2. Hybride comme Transition-vers-Agile

Beaucoup d’équipes ne sont pas capables de basculer vers les façons de travailler en mode Agile d’un jour à l’autre. Plus l’organisation est grande, plus ses composantes sont en mouvement, plus longtemps il faudra pour changer. Si vous avez vécu dans un monde prédictif depuis de nombreuses années, les méthodes Agiles paraitront très différentes. En conséquence, votre incursion initiale dans le monde Agile sera un amalgame peu ordonné des deux. C’est OK. Vous utilisez des techniques spécifiques pour vous déplacer dans la direction vers laquelle vous voulez aller.

Chaque projet a des besoins différents. Pour ceux qui se trouvent dans un environnement surtout prédictif, une approche hybride peut être une transition vers davantage d’adaptabilité et de livraisons. Pour ceux qui ont déjà adopté la livraison et l’adaptation agressives, incorporer quelques nouvelles techniques peut encore hausser votre challenge.

Ne déclarez pas simplement “Nous sommes Agiles”, la réalité est que vous utilisez déjà presque toujours une combinaison de techniques différentes. Au lieu de cela, une meilleure stratégie serait de vous poser et de réfléchir à quelles approches seraient les meilleures pour ce que vous voulez réaliser en fonction de là où vous êtes.

Weighted Shortest Job First (WSJF) est un modèle de priorisation des exigences dans les projets

Le 19 décembre 201814 décembre 2018 par mopertodans agile, outils et méthodesLaisser un commentaire

WSJF est utilisé pour séquencer les travaux dans l’optique de générer un bénéfice maximal: Fonctionnalités, Epics et User Stories Scrum.

Le Weighted Shortest Job First est calculé en divisant le « coût du retard » par la taille de la tâche à réaliser pour répondre au besoin, à l’exigence.

Ce « coût du retard » est la somme de trois estimations :

la valeur pour le business et les utilisateurs,
la criticité temporelle et
la réduction de risques ou création d’opportunités.

WSJF est donc utilisé pour prioriser l’arriéré de produit en calculant le coût du retard par rapport à la taille de la tâche (à défaut de durée).

L’utilisation du WSJF à chaque planning de Release et de Sprint maintient les priorités des arriérés de produit à jour en prenant en compte la valeur pour les utilisateurs et le business, les impacts de délais, les risques et opportunités ainsi que les efforts à fournir pour répondre à l’exigence.

Deux vidéos pour aller un peu ou beaucoup plus loin (en 3 et 20 minutes)

2 pages utiles

WSJF – Weighted Shortest Job First sur Black Swan Farming
Weighted Shortest Job First sur © Scaled Agile, Inc

C’est dans la comparaison relative des WSJF des différents items de l’arriéré de produit et dans la transparence de la priorisation que réside la force de cette technique.

Il me semble qu’il reste aussi à intégrer dans la priorisation les dépendances entre les besoins ou réponses aux besoins qui peuvent grandement influencer le séquencement des travaux.

Florilège de billets et vidéos sur le célèbre MVP (Minimum Viable Product)

Le 5 décembre 20185 décembre 2018 par mopertodans agileLaisser un commentaire

Voici 2 vidéos et 3 billets que j’ai trouvés intéressants sur ce sujet qui se trouve au cœur même de l’agilité.

L’approche MVP (Minimum Viable Product) est une stratégie de conception par la réalisation d’une version produit simplifiée. Elle permet à une équipe de recueillir de manière itérative et incrémentale une quantité maximale de retours validés par des « early adopters ». Elle permet aussi de répondre très vite au besoin client et de le satisfaire à terme bien mieux qu’avec les méthodologies classiques.

En langue anglaise: A minimum viable product is a great way of building user centric digital services in a fraction of the time. It will also lead to big cost savings.

Retrouvez ces billets précédemment publiés sur DantotsuPM.com

1. pensons Produit Minimum Viable (MVP)

Un livre de référence sur ce sujet disponible sur Amazon

Un des buts atteint par Eric Ries’ Lean Startup’ et porteur du plus de valeur est de populariser le terme de « Minimal Viable Product » (MVP), ou Produit Minimum Viable en français. Bien sûr, le concept n’est pas nouveau. Nous utilisions l’idée de « Minimal Marketable Feature » (MMF) depuis les tous premiers jours de Kanban et elle était basée sur la même façon de penser.

2. Vaut-il mieux un livrable parfait et en retard qu’acceptable et dans les temps ?

Dans la plupart des sociétés et organisations la réponse est « acceptable et dans les temps ». Aussi, comme le prônent les méthodes Agile et les concepts tels que le Produit Minimum Viable (MVP), respecter un délai sans être paralysé par la recherche de perfection est-il vital pour l’entreprise.

3. Projet Maximum Faisable

Pour finir, Seth Godin nous challenge un peu sur cette « évidence » de l’agilité…

Les Lean entrepreneurs parlent de MVP (minimum viable product: produit viable minimal), mais bien plus important est le Projet Maximum Faisable.

Étant donné les ressources à votre disposition (vos moyens, votre temps, votre patience), quel est le plus gros résultat que vous pensez pouvoir atteindre ?

regardons ensemble une technique pour nous aider à prioriser notre arriéré de produit

Le 26 novembre 201825 novembre 2018 par mopertodans agileLaisser un commentaire

Bien prioriser les items dans l’arriéré de produit est l’une des difficultés que nous rencontrons très souvent.

A technique to help Prioritise your Backlog

http://www.growingagile.co.za/2014/06/a-technique-to-help-prioritise-your-backlog/ par Sam Laing

En tant que Propriétaire de Produit (« Product Owner ») pensez-vous jamais que …. ?

vous avez trop de travail et pas assez de temps.
vous avez trop de demandeurs criant pour que leurs besoins passent en premier.
vous n’avez jamais de temps pour adresser la dette technique ni l’innovation parce que le directeur commercial continue d’exiger de nouvelles fonctionnalités.

Bien prioriser les items dans l’arriéré de produit est l’une des difficultés que nous rencontrons très souvent. Avoir un arriéré correctement ordonné apporte de la valeur. Cela garantit que votre équipe travaille sur les articles les plus importants pour le business et que votre produit évolue dans la bonne direction. Votre travail le plus important de Propriétaire de Produit est de décider comment utiliser au mieux la capacité de votre équipe.

Nous avons une technique que nous enseignons aux Propriétaires de Produit pour les aider à accorder la bonne priorité aux différentes parties prenantes.

Le schéma ci-dessous montre une façon de représenter tout le travail possible sur 2 axes : le temps et qui le travail aide le plus.

Selon notre expérience, il est plus facile de faire tomber d’accord vos parties prenantes sur le fait que (par exemple) les fonctionnalités pour supporter les nouveaux clients devraient consommer au plus 50 % de votre bande passante ou qu’un item spécifique de la dette technique est plus important qu’une fonctionnalité client donnée. Une fois que vous avez un agrément sur le pourcentage de capacité à dépenser dans chaque secteur, vous pouvez demander aux parties prenantes de chacun des quadrants de donner leurs priorités par quadrant sur la meilleure façon d’utiliser leur part de la capacité disponible.

Faire l’exercice avec l’équipe puis élargir à d’autres

Passé et Business (Support)

Passé se réfère ici aux fonctions existantes ou aux clients existants. Business se réfère aux parties prenantes qui se préoccupent d’articles dont les clients se soucient le plus. Les articles de ce quadrant sont d’habitude appelés des articles de support ou de soutien. Cela pourrait être les corrections à des erreurs signalées par des clients, ou des améliorations mineures à une fonctionnalité déjà livrée pour rendre la vie plus facile au client existant. Les articles de ce quadrant ne vous font pas gagner de nouveaux clients, mais ils ont un impact sur la conservation et la satisfaction des clients existants. Aussi ce quart de cercle est-il souvent financé par la maintenance et des contrats de support, et peut en fait être un quadrant qui génère effectivement du revenu.

Futur et Business (Nouveau Business)

Ce quadrant est souvent le seul sur lequel les gens se concentrent, particulièrement s’il y a une grosse pression pour gagner de nouveaux clients. Les articles de ce quadrant ont pour objectif d’aider à attirer plus de clients dans l’avenir. Ce pourraient être de nouvelles fonctionnalités, permettre une montée en volume, ajouter une plate-forme supplémentaire destinée à servir un nouveau type d’utilisateurs.

Passé et Technique (Dette Technique)

C’est un quadrant trop souvent négligé. Essentiellement, ce sont les articles qui impactent l’équipe technique. La dette technique en est un bon exemple. Par exemple, une fonctionnalité pourrait avoir été mal écrite et être donc très fragile, générant des bogues chaque fois l’équipe travaille dessus. Habituellement, ces articles ne génèrent pas de revenu additionnel mais, si on les choisit bien, ils peuvent être de gros économiseurs de dépenses. Un autre exemple dans ce secteur pourrait être une chose qui fera gagner beaucoup de temps à l’équipe de support. Par exemple si votre personnel de support doit résoudre des problèmes complexes, capturer des informations complémentaires lors de la connexion pourrait être quelque chose qui les aidera à réduire le temps qu’ils dépensent dans leurs investigations.

Futur et Technique (Innovation Architecturale)

Ce quadrant est une projection dans le futur d’une vue technique. Souvent les architectes peuvent proposer des idées pour ce secteur. Peut-être qu’une nouvelle technologie est disponible qui simplifiera significativement votre produit. D’autres items pourraient être des mises à niveau de technologies existantes avant que celles que vous utilisez ne soient dépassées. Par exemple, mise à niveau sur la dernière version Java. Ces articles peuvent parfois rapporter du revenu additionnel, parce qu’ils attirent les clients, mais le plus souvent ce sont des réducteurs de coûts : la nouvelle technologie devrait rendre les développements plus faciles pour votre équipe.

Et ci cela pouvait aussi s’avérer utile comme approche générique pour prioriser un portefeuille de projets ?

C’est une technique que nous utilisons dans notre livre “Growing Agile: A Coach’s Guide to Mastering Backlogs”.

Comment mieux jouer au Planning Poker ?

Le 31 octobre 201829 octobre 2018 par mopertodans agile, best practicesLaisser un commentaire

Le Planning Poker^® peut paraitre complexe pour ceux qui deviennent juste de commencer à l’utiliser.

Tips for Playing Planning Poker

https://www.scrumalliance.org/community/articles/2017/september/tips-for-playing-planning-poker par Shane Billings

Voici quelques conseils et suggestions pour vous aider à mieux utiliser cette technique.

Règles de base

Avant que le jeu ne démarre, l’équipe identifie une histoire de référence. La complexité, la durée et le risque associé à cette histoire sont compris de tous les membres d’équipe. On donne à l’histoire de référence une valeur numérique de 2 ou 3. Cette histoire sert de base de référence pour toutes les histoires à venir et est utilisée pour lui comparer le nouveau travail à réaliser.

Une histoire est discutée jusqu’à ce que tous les membres de l’équipe comprennent bien son contenu. En utilisant des cartes physiques ou des méthodes électroniques, les membres d’équipe choisissent un nombre de Fibonacci (1, 2, 3, 5, 8, 13, 21…). Cela représente le rapport entre la nouvelle d’histoire et l’histoire de référence. Cette « mise » de chaque membre d’équipe représente la complexité, la taille, la durée et le risque de la nouvelle histoire par rapport à l’ancienne. Par exemple, si une histoire de référence vaut 2 et que la nouvelle histoire est 4 fois plus grande, une mise de 8 serait choisie. Cachez vos cartes jusqu’à ce que ce soit le moment pour que tous les membres de l’équipe dévoilent en même temps leur estimation personnelle. Comparez les mises et discutez des différences entre elles. Répétez l’exercice jusqu’à ce que tous les membres d’équipe soient à au plus 1 niveau d’écart les uns des autres dans la séquence de Fibonacci. Accordez-vous sur le bon nombre au niveau de l’équipe.

Conseils et suggestions

Vous ne pouvez pas être 100 % précis, n’y passez donc pas trop de temps. Personne ne connait l’avenir avec précision.
Bien que vous ne puissiez pas prévoir l’avenir, vous constaterez que l’équipe est très précise et ses membres sont précis avec seulement très peu de temps investi.
N’y réfléchissez pas trop. Déterminez comment ils ressentent l’histoire. Parce que vous utilisez des tailles relatives, votre cerveau sait intuitivement le nombre sans trop y réfléchir. La conversation quant aux différentes évaluations donnera assez de profondeur pour évaluer plus précisément.
La séquence de Fibonacci a des espaces qui augmentent au fil de la suite de nombre. Utilisez ces espaces pour indiquer l’inconnu. Plus un travail est grand, plus il contient d’inconnus.
Considérez le risque dans le nombre. Utilisez des nombres plus élevés pour prendre en compte le risque en indiquant que le travail restera moindre que le nombre choisi. Le risque pousse l’estimation vers le haut.
Ne reprenez pas ni réparez vos évaluations qui étaient fausses. Vos erreurs entreront dans la moyenne après quelque temps.
La discussion est d’autant de valeur que l’évaluation. Le point du jeu est d’aligner, de communiquer, de comprendre et d’éliminer les fausses idées. Chacun devrait avoir une voix.
Utilisation l’option « ? » au lieu d’un nombre pour les histoires pour lesquelles vous êtes incapable de donner une évaluation. Cela devrait être plus confortable pour ceux qui ne sont pas en position de formuler une évaluation.

Tenez vos mises cachées jusqu’à ce qu’il soit temps de jouer.

Il y aura toujours quelqu’un qui basera sa mise sur celle de quelqu’un d’autre. Cela limite les possibilités de conversation.

Pour aller plus loin

AgileSHIFT : Poser un cadre d’ensemble pour Agile, par Henny Portman

Le 24 octobre 201824 octobre 2018 par mopertodans agile, formations et certifications, outils et méthodesLaisser un commentaire

De trop nombreuses organisations ont du mal ou même échouent purement et simplement à mettre en œuvre des structures pour accroitre leur niveau d’agilité.

Une des raisons est la rupture de culture entre une organisation traditionnelle et la culture agile. Mettre en place des structures de livraison Agiles seulement dans votre service informatique ne suffit pas.

Un aperçu de la méthode est téléchargeable en ligne

AXELOS a développé un cadre de référence qui prépare les gens au changement transformationnel en créant une culture d’agilité d’entreprise. La structure AgileSHIFT aide les organisations à réaliser un changement transformationnel, à adopter une mentalité ‘ survivre, rivaliser et prospérer. Elle aide à construire un pont entre l’état actuel et l’état cible (le Delta dans AgileSHIFT) en embrassant un ensemble d’approches agiles, structurées et hybrides à travers toute l’organisation. La déconnexion existante entre ‘Faire tourner la boite’ et ‘Changer le business’ disparaît (Run the Organization et Change the Organization).

Chaque personne est une activatrice de changement, encouragée et autorisée à faciliter cette évolution.

Télécharger : AgileSHIFT (QRC, 181012) v1.0

Le cadre de méthode AgileSHIFT explique pourquoi nous avons besoin de l’agilité d’entreprise. Il y a une rapidité d’occurrence des changements qui accélère : volatilité, incertitude, complexité, ambiguïté (VUCA). Le rôle de la technologie évolue de « supporté par la technologie » vers « la technologie au centre de tout » en passant par « facilité par la technologie » . L’écart augmente entre l’état actuel et désiré pour votre organisation. Les influences perturbatrices comme le travail à distance, le stockage dans le cloud, la présence en ligne, les marchés inefficaces et des événements totalement inattendus contribuent à ces évolutions forcées.

Pour leur faire face, nous devons adopter le cadre et la structure proposés par AgileSHIFT qui définissent l’agilité d’entreprise, ses principes et ses pratiques. L’agilité d’entreprise est la capacité d’une organisation à bouger et s’adapter rapidement pour répondre aux changements des clients et des besoins du marché.

Les cinq principes

Le Changement se produira aussi embrassez le statu quo
Challengez le statu quo
Développez un environnement où chacun ajoute de la valeur
Concentrez-vous sur la co-création de valeur pour le client
Adaptez votre approche

Les cinq pratiques

Planifiez d’être flexible et adaptable
Engagez avec les parties prenantes
Construisez des équipes collaboratives
Concentrez-vous sur la co-création de valeur
Mesurez cette valeur pour le client

Le comment (correspond à l’approche de livraison AgileSHIFT)

Il s’exprime dans la structure AgileSHIFT par les rôles, le « workflow » (flux de travail) AgileSHIFT, une approche itérative et des outils et techniques.

Il y a 3 rôles : l’équipe AgileSHIFT, le sponsor et le coach.

Une approche itérative simple y est expliquée mais selon la situation vous devrez choisir la bonne approche. Les outils et des techniques incluent les histoires client (User Stories) et les épopées (Epics), les estimations relatives et les points d’histoire, la liste des tâches et la « roadmap » (feuille de route) AgileSHIFT, l’essaim, kanban, des canevas et agendas.

Des téléchargements sont disponibles pour les deux derniers.

Pour montrer votre compréhension d’AgileSHIFT, une certification basique et de praticien seront possibles.

Dans l’image suivante, Henny Portman a positionné AgileSHIFT par rapport aux autres approches et méthodes.

Pour aller plus loin, un wébinaire en langue anglaise est proposé par Axelos

le 31 Octobre à 8:00 GMT : An agile solution for the entire organization: Introducing AgileSHIFT®

Agile : Comment accélérer le métabolisme de votre société ?

Le 17 octobre 201816 octobre 2018 par mopertodans agileLaisser un commentaire

Pour des organisations tenant à adopter une nouvelle façon de travailler, voici cinq étapes clefs pour inspirer une transformation vraiment saine et Agile

Agile How to increase your company’s metabolism

http://www.cbronline.com/news/enterprise-it/agile-increase-companys-metabolism/ par Fleur Bamber

‘Agile’ a été présentée comme un remède à bien des maux de l’entreprise, y compris comment surmonter la rigidité organisationnelle. Beaucoup d’organisations ‘rigides’ continuent à utiliser les systèmes du 20ème siècle de type commande-et-contrôle du sommet vers le bas, avec des processus onéreux de direction et un outillage qui incite à la conformité plutôt qu’à la créativité et la responsabilisation. Certains commencent aussi à « faire Agile » et « embrasser Agile » sans consensus clair sur la vraie définition de cette approche, ou comment Agile peut aider une société à réussir dans le monde actuel en constant mouvement.

encore une autre expression à la mode ?

Reconnaissons-le, Agile est devenu le mot à la mode, après ses prédécesseurs comme ‘synergie’. Pour ma part, je n’ai pas d’objection si Agile est mentionné avec un A majuscule. Ce dont je me soucie vraiment est d’appliquer des concepts Lean comme ‘inspecter et adapter’, ‘limiter le travail en cours’ et ‘éliminer les gaspillage’. Je veux utiliser dès aujourd’hui les meilleures pratiques dans le développement de produit pour accélérer les bonnes réactions des marchés, en augmentant quelque chose que j’appelle ‘le métabolisme organisationnel’.

Qu’est-ce que le métabolisme organisationnel ?

Dans la nature, c’est le processus chimique qui se produit dans des organismes vivants pour convertir l’alimentation en énergie tout en éliminant les gaspillages. Dans le monde des affaires, cela traduit par un système qui convertit des actifs, incluant l’argent, les personnes et le temps, en valeur pour le client, idéalement en réduisant au minimum les coûts déraisonnables (par exemple la bureaucratie).

Travailler plus intelligemment

Les pratiques existantes consistant à bosser simplement plus dur que la compétition ne suffiront pas. Nous faisons face à une nouvelle réalité où les clients s’attendent à des nouveautés en continu et des innovations sur ce qu’ils veulent et ce dont ils ont besoin. En particulier tout ce qui est facilité par le digital.

Pour rester à niveau et même prendre les devants sur les concurrents, les organisations doivent abandonner leur métabolisme lent en faveur d’un business du 21e siècle au pied léger, délivrant rapidement de la valeur.

Ils peuvent le faire en développant les personnes, processus et outils qui accélèrent le métabolisme de leurs sociétés. Les sociétés qui laisseront s’échapper cette nouvelle façon de travailler louperont des opportunités pendant que leurs concurrentes prendront de l’avance, laissant lzurs clients prêts à explorer des solutions alternatives.

1. Maintenez une vision claire et inspirante

Clairement définir les résultats attendus, tant pour votre organisation que dans la transformation agile de votre société, est essentiel, parce qu’avoir une mentalité Agile signifie être à l’aise avec le changement. Tandis que les tâches et la tactique changeront, la vision suprême devrait rester intacte.

Chaque société est différente, mais doit avoir une image claire de sa raison d’être et du résultat visé.

Demandez-vous : Quel est le résultat dont je me soucie et qu’est-ce que je demande en réalité aux gens de faire ? Une vision claire aidera à guider les pratiques qui doivent être mises en œuvre malgré les changements des marchés et les fluctuations des opérations internes.

2. Considérez la culture

Pour attirer et conserver les meilleurs personnes, vous devez créer un environnement dans lequel elles peuvent prospérer. Un environnement convenable est celui dans lequel la population d’employés est motivée, autonome et suit les meilleures pratiques qui délivrent de la valeur.

**The best PMs are outstanding leaders**

Les leaders devraient considérer : Comment est-ce que je supporte mes premières lignes d’employés ? Ils ont les positions à l’écoute de mes clients, ils s’engagent avec eux. Donner le pouvoir aux premières lignes de personnel rend plus facile pour l’organisation d’appréhender les changements et de s’y adapter.

Des organisations qui dirigent ‘du haut vers le bas‘ deviennent lentement des dinosaures et les organisations qui adoptent ce changement culturel d’autoriser la ligne frontale à prendre des responsabilités et fournit des boucles de réactions productives seront celles qui réussissent. De plus, les leaders doivent montrer l’exemple. Trop souvent, les leaders s’attendent à ce que leurs employés mettent en œuvre des pratiques Agiles sans changer leur propre comportement.

3. Processus de changement d’idée

Beaucoup de processus et systèmes commerciaux utilisés aujourd’hui ont été créés il y a des décennies, dans l’optique d’automatiser des processus commerciaux standards. Cependant, ces processus commerciaux standards ont été construits en adaptant des processus de fabrication de grand volume d’articles physiques.

Comme les sociétés améliorent leur métabolisme organisationnel, les leaders doivent repenser tous les processus et systèmes car ceux qui les ont faits avancer au 20^ème siècle ne peuvent pas répondre aux exigences de retours plus rapides d’aujourd’hui.

Le lieu de travail actuel a besoin de processus pour la direction et la conformité mais aussi pour que les personnes gagnent en autonomie en reconnaissant la façon dont elles vivent et travaillent de nos jours.

4. Utilisez les meilleurs outils

Les bons outils peuvent amplifier la direction et la vision, enlevant les frictions qui trop souvent gênent la transformation. Les outils renforcent de bons processus et comportements, évaluent quantitativement les résultats désirables et soutiennent l’équipe pour faire les ajustements corrects. Même les sociétés les plus récentes souffrent d’un métabolisme lent si elles utilisent des outils et des systèmes dépassés. Qu’il s’agisse d’une plate-forme de développement de logiciel, du système de gestion des feuilles de temps, ou de la nouvelle plateforme collaborative, les outils modernes devraient réduire la charge de travail totale, pas l’augmenter.

5. Soyez ouvert à l’échec, apprenez et adaptez-vous

Les employés ne devraient pas avoir peur de perdre leurs emplois s’ils prennent un risque intelligent et échouent. Ce devrait être évident, mais ce n’est pas le cas dans la réalité de la plupart des sociétés. Un certain niveau d’échec est inévitable quand la culture, les processus et les structures d’une organisation changent fondamentalement.

Cela fait partie de l’innovation

Des risques calculés devraient être encouragés dans les sociétés modernes. La chose importante est d’apprendre de toute erreur et devenir plus intelligent. ‘La mise à l’épreuve et l’apprentissage’, pas ‘la perfection’, devraient être nouveau mantra.

Le business au 21^ème siècle

L’accélération du métabolisme organisationnel exige d’avoir suffisamment de discipline pour examiner le système en entier, de la même façon qu’un athlète professionnel améliore continuellement ce qu’il mange, comment il s’entraine, les buts qu’il se fixe et l’attitude qu’il met en place pour devenir le meilleur du monde.

Les athlètes ‘ne courent pas sur place ’

Ils cherchent continuellement des améliorations et s’entrainent activement, mettant en œuvre les pratiques qui les verront franchir en premier la ligne d’arrivée.

De même, les sociétés doivent constamment s’efforcer de s’améliorer. La transformation est une difficulté mais elle est essentielle pour les sociétés qui veulent devenir et rester des succès.

Bien que ce ne soit pas toujours facile, quand des sociétés, des équipes et des individus font l’effort, ils sont dans une bien meilleure position pour rivaliser et délivrer pour leurs clients.

version 2017 du Scrum Guide en Français (gratuite) et qu’est-ce qu’un ScrumMaster ?

Le 28 septembre 201828 septembre 2018 par mopertodans agile, pointeurs utiles1 commentaire

Connaissez-vous le site Scrum.org?

On peut y trouver des guides, dont les dernières versions du Scrum Guide écrit par Ken Schwaber et Jeff Sutherland: Scrum Guide, PDF gratuit, en de nombreuses langues dont le français

On y trouve aussi des détails sur les programmes Professional ScrumMaster et Professional Scrum Developer avec des tests payants en ligne pour valider votre niveau de connaissance de Scrum et des rôles des différents intervenants sur les projets Agiles.

Petite vidéo très vivante de Romain Couturier sur le rôle de Scrum Master

Avec l’essor massif de l’Agilité dans les organisations et plus particulièrement de la méthode Scrum, un nouveau rôle est apparu : Scrum Master. Peut-il développer ? Quelles sont ses missions ? Cette vidéo devrait vous permettre de faire le tri entre les mythes et réalités qui entourent ce rôle. En bonus vous repartirez avec quelques outils bien pratiques dans votre rôle quotidien de Scrum Master.

le rapport annuel de Version One sur l’état de Agile est disponible

Le 26 septembre 201826 septembre 2018 par mopertodans agile, pointeurs utilesLaisser un commentaire

The state of Agile Survey de Version One.

Pas de surprise côté méthodes, SCRUM reste fortement majoritaire à plus de 50%, même si l’on commence à voir une percée des approches hybrides.
En ce qui concerne l’agilité à l’échelle, rien de très nouveau. SAFe continue de dominer. Même s’il n’est utilisé que dans moins du tiers des cas, SAFe distance cette année plus largement ses compétiteurs comme Scrum of Scrums.
Le point le plus positif selon moi du rapport est que les bénéfices attendus des projets Agiles sont au rendez-vous et dépassent même souvent les attentes des organisations.

Téléchargez gratuitement le rapport annuel de 16 pages

Merci à Florence Duverneuil pour le pointeur

Importance de la co-localisation dans la collaboration

Le 27 août 201822 août 2018 par mopertodans agile1 commentaire

Avec Agile, une communication large-bande est nécessaire !

Importance of Colocation in Collaboration

https://www.scrumstudy.com/blog/importance-of-co-localisation-in-collaboration/ par SCRUMstudy

Pour beaucoup des aspects pratiques de Scrum, la communication large-bande est exigée.

Pour le permettre, il est préférable que les membres d’équipe soient localisés géographiquement au même emplacement. La co-localisation permet des interactions tant formelles qu’informelles entre les membres de l’équipe. Cela fournit l’avantage d’avoir les membres d’équipe toujours à portée de main (et de voix) pour la coordination, la résolution de problèmes et pour apprendre.

Certains des bénéfices de la co-localisation

Les questions trouvent rapidement des réponses.
Les problèmes sont fixés dans l’instant et sur place.
Moins de friction entre les interactions.
La confiance est gagnée et allouée beaucoup plus rapidement.

Des outils de collaboration peuvent être utilisés pour les équipes co-localisées ou distribuées

1. Équipes co-localisées (c’est-à-dire, équipes travaillant dans le même bureau)

Avec Scrum, il est préférable d’avoir des équipes co-localisées. Si co-localisées, les modes préférés de communication incluent des interactions en face à face, des salles partagées ou War Rooms, des tableaux Scrum, des affichages muraux, des tables partagées, etc.

2. Équipes distribuées (c’est-à-dire, équipes travaillant dans emplacements géographiques/physiques différents)

Bien que des équipes co-localisées soient préférables, de temps en temps l’équipe Scrum peut devoir être distribuée pour des raisons d’externalisation, d’offshoring, de sites géographiques multiples, d’options de travail-à-la-maison, etc. Certains outils à utiliser pour une collaboration efficace avec des équipes distribuées incluent la communication par vidéo, la messagerie instantanée, les outils de chats, les médias sociaux, les écrans partagés et les outils logiciels qui digitalisent la fonctionnalité des tableaux Scrum, murs partagés, et cetera.

Coûts supplémentaires à prévoir impérativement

Si la co-localisation n’est pas possible et qu’il y a des équipes distribuées,des ressources complémentaires devront être consacrées à faciliter des communications.

Ainsi qu’à comprendre les différences culturelles, synchroniser le travail et favoriser le partage de connaissance.

Juillet 2018 fut l’occasion de revenir sur quelques fondamentaux dans nos vies de chefs de projet (et en dehors)

Le 24 août 201822 août 2018 par mopertodans agile, best practicesLaisser un commentaire

Ikigai, Cynefin, Manifeste Agile, confiance et devenir un bon mentor de projet, tels étaient les sujets qui vous intéressèrent le plus en Juillet.

l’ Ikigai est la raison de vous lever le matin

Chacun a un Ikigai, c’est notre moteur intrinsèque. Vous devez le chercher et l’identifier pour découvrir votre source personnelle de valeur dans votre vie ou les choses qui rendent votre vie digne d’être vécue. La découverte de son Ikigai apporte le sens, le bonheur et la satisfaction.

vous êtes chef de projet, ce n’est pas sans raison ! Ayez confiance en vos capacités.

Le Manifeste Agile, ses 4 valeurs et 12 principes, par QRP International

Le Manifeste Agile, ses 4 valeurs et 12 principes, sont la conséquence de la frustration des entreprises dans les années 1990 sur le laps de temps entre l’expression des besoins de l’entreprise et la livraison technologique de la solution. Les besoins business et métier évoluent pendant cette période et le produit final ne répond jamais aux besoins du moment qui ont changé.

QRP International est Partenaire de DantotsuPM

une approche pour comprendre et appréhender la complexité grâce au modèle Cynefin

Cynefin parle de quatre types différents de problèmes ou domaines. Évident, Compliqué, Complexe et Chaotique. Nous aborderons ces premiers et couvrirons à la fin le Désordre.

Comment être ou devenir un bon mentor de Chef de Projet en 6 étapes ?

Les débutants qui prennent leur premier job de management de projet ont besoin de quelqu’un pour les guider et les aider à passer l’environnement agité, cependant productif de ces tâches : un mentor.

Si vous êtes déjà un mentor de chef de projet, vous êtes déjà familiers avec cette situation; vous décelez les erreurs des débutants et êtes un peu frustré lorsqu’ils s’avèrent incapables d’accomplir le travail que l’on attend d’eux. Alors, vous appliquez les méthodes nécessaires pour les aider à sortir de leur tracas et à évoluer par eux-mêmes.

Si vous n’êtes pas encore un mentor de projet, mais voulez le devenir, voici quelques étapes pour vous assurer que votre protégé recevra autant de formation qu’il ou elle lui en faut pour survivre dans le management de projet.

Méta Projets Management est partenaire de DantotsuPM

SCRUM ne s’applique pas seulement dans le développement de logiciels, bien au contraire

Le 23 août 201822 août 2018 par mopertodans agile, outils et méthodes2 commentaires

Scrum est une méthode universelle

Il y a quelques années, Craig Brown qui anime le Melbourne Scrum User group a commencé à prôner que Scrum est une méthode universelle et non pas réservée uniquement aux projets de développement de logiciels.

Voici ce que je retiens encore aujourd’hui de la description qu’il donnait de Scrum et qui s’applique à tout projet :

1. Commencez avec un objectif. Puis, décomposez-le en étapes incrémentales.

2. Discutez des étapes avec l’équipe qui doit livrer la solution.

3. Définissez des périodes de temps standards (timebox) pour les itérations. Faites de votre mieux pour livrer quelque chose de valeur, utilisable et utile à chaque itération.

4. L’équipe prend ses « ordres » (ses priorités) du client au début de chaque itération et fait un rapport sur ce qui a été « fait » (totalement achevé) à la fin de chaque itération (Sprint Review).

5. L’équipe doit mettre du temps de coté au début de chaque itération pour planifier son travail (Sprint Planning).

6. L’équipe doit aussi mettre du temps de coté pour une brève session d’échanges chaque jour entre ses membres sur les progrès réalisés et les problèmes rencontrés (Daily Scrum).

7. L’équipe doit s’engager à l’amélioration continue et mettre du temps de coté à chaque itération pour réfléchir à ce qui est bien allé ou pas et identifier où l’on peut s’améliorer et comment (Sprint Retrospective).

8. La planification, la revue et les sessions de réflexion et réunions d’équipe quotidiennes doivent avoir lieu à des heures régulières pour aider l’équipe à trouver et tenir un rythme.

plusieurs astuces utiles pour les chefs de projet dans les articles les plus lus sur le blog DantotsuPM en Juin 2018

Le 22 août 201821 août 2018 par mopertodans agile, best practices, experience sharingLaisser un commentaire

Cette “Règle 1-3-5” peut complètement changer votre To-Do Liste !!!

Essayez-vous de tout accomplir, seulement en vous consommant et finissant par vous sentir toujours plus en retard ?

S’il en est ainsi, vous n’êtes pas tout seul.

J’ai personnellement essayer cette technique et elle marche mais demande énormément de rigueur et d’attention. Les premiers temps, mes estimations de durée entre les choses grandes, moyennes et plus petites, étaient erronées et bien sûr il est souvent difficile d’avancer comme on le voudrait sur sa to-to Liste à cause des impondérables opérationnels de la vraie vie au travail.

Que faire quand une personne s’accapare la discussion ?

Comment le manager ou le chef de projet devrait-il gérer un dominateur pendant une réunion d’équipe ?

Le Problème : Chacun a eu l’occasion de rencontrer “LE dominateur” (ou LA dominatrice).

C’est la personne dans le groupe qui semble s’approprier la discussion et ne plus laisser d’autres personnes s’exprimer. Parfois ce sont seulement des bavards trop prolifiques… …d’autres fois, ce sont des personnalités excessivement agressives qui pompent tout l’oxygène de la pièce.

3 pratiques Agiles faciles que votre équipe peut commencer dès aujourd’hui

Vous avez entendu vos amis chanter les louanges d’Agile. Vos copains chefs de projet deviennent des scrum masters. Vous entendez combien c’est formidable. Tous les gamins dans le coup le font et vous êtes un peu jaloux. Vous vous sentez exclu. Vous voulez voir l’objet de toute cette agitation.

Bonnes nouvelles ! Il existe des pratiques Agiles que vous pouvez utiliser même dans votre monde prédictif en cascade. Vous obtiendrez les bénéfices d’une communication accrue, de la collaboration avec le client et de l’amélioration continue. Et vous aurez une opportunité de présenter quelques pratiques Agiles à votre équipe. Sans devoir vous coller à la transition de l’organisation toute entière vers Agile.

Que signifie vraiment “le Produit Viable Minimal” ou mVP de toute façon ?

Un processus MVP simplifié en 3 étapes

Source : Egg Lighting

Commencez avec un produit simple et unique résolvant un minuscule sous-ensemble d’un grand problème;
Continuez à itérez, en résolvant constamment de plus grands problèmes connectés à la résolution du grand problème;
Communiquez constamment la vision du grand problème qui sera résolu.

10 bénéfices à connaître sur le Management Portefeuille de Projet

Dans ce billet sont listés Dix Bénéfices du Management de Portefeuille de Projet qui aideront votre projet à recevoir l’attention qu’il mérite. Ces bénéfices sont aussi accompagnés par le Bureau de Management de Projets (Project Management Office / PMO) pour améliorer votre taux de succès dans les projets.

Mai 2018 – articles les plus lus par les lecteurs du blog DantotsuPM

Le 20 août 201820 août 2018 par mopertodans agile, experience sharing, outils et méthodes, pmo et portofolioLaisser un commentaire

Management de projet hybride, nouveaux guides du PMI, outils Microsoft… mais aussi se comporter en adulte furent les billet qui retinrent votre attention en Mai 2018 et que vous aimerez peut-être relire ou découvrir en cette période estivale plus calme.

« une main de fer dans un gant de velours » avec les approches prédictives et Agile selon Christine Rieu, Sylvain Gautier et Marc Burlereaux

Cet article publié il y a plusieurs années et repris à l’occasion du forum des régions PMI France 2018 a connu un regain de succès. C’est très mérité car les auteurs, Christine Rieu, Sylvain Gautier et Marc Burlereaux, avaient pris le temps de partager avec nous leur expérience de l’agilité et premières idées pour adopter une approche plus hybride.

L’approche Agile dans les projets de développement de nouveaux produits permet d’assurer plus de souplesse dans la conception itérative, plus de légèreté dans la documentation et dans la formalisation, plus d’interactivité et d’efficacité dans la conduite de réunions, et surtout plus d’implication du client tout au long du projet. En couplant une approche Lean à ces méthodes Agiles, nous supprimons en plus toutes les étapes inutiles sans valeur ajoutée pour limiter les gaspillages et maximiser ainsi la valeur attendue du produit.

Une liste de 25 principes de comportement adulte par John Perry Barlow

Quand il avait 30 ans, le fondateur de l’Electronic Frontier Foundation (et parfois parolier de Grateful Dead) a rédigé une liste de ce qu’il a appelé « les Principes de Comportement Adulte ». Lesquels 5 ou 6 éliriez-vous dans cette liste pour votre propre éthique ? J’aime beaucoup 2,3,4,5,6,7,8…

…impossible de choisir.

Microsoft Planner ou Microsoft Project: Lequel utiliser pour manager vos projets ?

À ce jour, vous êtes probablement déjà familiers de Microsoft Project. Sorti en 1990, Microsoft Project est devenu l’application par défaut pour les chefs de projets. Microsoft Planner est une solution de gestion de projet plus récente qui a été publiée en 2016 dans le cadre d’Office 365. Les deux applications nous laissent créer des plans, organiser et confier des tâches, partager des dossiers, communiquer avec des collègues et obtenir des mises à jour sur le progrès de notre équipe.
Alors, quelle solution devrions-nous utiliser ?le combiné « Guide PMBOK® + Guide pratique des méthodes Agiles » du Project Management Institute est disponible en français
Afin de soutenir l’éventail de plus en plus large des approches de réalisation de projets, PMI propose un PMBOK® Guide – Sixième édition accompagné du nouveau Guide de pratiques Agiles.

En mode ‘Ciel, mon outil PPM !’, 6 points-clé à ne pas manquer pour réussir le choix de sa solution de pilotage des projets !

Quand le sujet de choisir son outil PPM devient un vrai casse-tête, que vous vous perdez devant la pléthore d’offres et que vous ne savez plus vraiment comment faire le bon choix…

Pas de panique, détendez-vous ! On vous dit tout !

quels billets les suiveurs du blog DantotsuPM ont-ils le plus aimés en Mars 2018 ?

Le 14 août 20185 août 2018 par mopertodans agile, experience sharing, outils et méthodesLaisser un commentaire

Outils, méthodes, retour d’expérience, PMO… ces sujets variés du mois de Mars 2018 ont retenu votre attention.

une check-list simple et concrète pour vérifier si nous faisons vraiment du Scrum ou nous y préparer et améliorer

Voici une check-list fort utile et déjà très utilisée qui est traduite en de nombreuses langues dont le français !

qu’utilisez-vous pour documenter les Rôles et Responsabilités ?

La RAM, Responsibility Assignment Matrix, ou Matrice d’Affectation des Responsabilités sert à documenter les rôles et responsabilités de chacun dans le projet.

Cet outil, qui prend la forme d’un tableau (qui croise la structure de décomposition du projet/WBS et les ressources de l’organisation) permet au chef de projet de lister les participants au projet ainsi que leur(s) responsabilité(s).

Le RACI est l’exemple de RAM le plus utilisé, a pour point de départ le croisement de la structure de découpage de projet ou SDP/WBS avec les ressources du projet.

Est-ce un projet ou une activité régulière ? Comment faites-vous la différence entre les 2 ?

« Qu’est-ce qui différencie les projets des activités régulières ? »: Lors de votre prochain entretien pour un job de chef de projet, cette question pourrait fort bien vous être posée.

Alors, que répondre ? ==> 3 éléments majeurs

voici les principes de base d’un chercheur en physique, ils s’appliquent fort bien au management de projets

Une lettre d’un chercheur en physique au Laboratoire Lawrence Livermore du nom de Tom Hirshfield. Tom y partageait quelques principes de base qu’il avait personnellement trouvés utile dans son travail et à utiliser comme bon vous semble dans le votre.

Selon vous, quelles sont les étapes majeures pour mettre en place notre PMO ?

Voici quelques-unes des étapes sur lesquelles je plancherais pour préparer un plan à 90 jours que je pourrais proposer à mon futur employeur dès les premiers entretiens…

Qu’est-ce que le “Scrum of Scrums” ?

Le 6 août 20185 août 2018 par mopertodans agileLaisser un commentaire

What is Scrum of Scrums?

https://www.scrumstudy.com/blog/what-is-scrum-of-scrums/ par SCRUMstudy

Qu’est-ce que le Scrum of Scrums et comment fonctionne-t-il dans le processus de développement de produit ?

La première chose à savoir sur le Scrum of Scrums est qu’il devient pertinent seulement pour de grands projets où de multiples équipes Scrum sont impliquées. Dans ce processus, les représentants d’équipes Scrum se rassemblent pour la réunion Scrum of Scrums à intervalles de temps prédéterminés ou chaque fois qu’il est nécessaire de collaborer et suivre leurs progrès, obstacles et dépendances respectifs à travers les multiples équipes Scrum.

Qui participe ?

Normalement, un membre de chaque équipe Scrum représentera son équipe dans la réunion Scrum of Scrums. Dans la plupart des cas, c’est le Scrum Master, mais de temps en temps quelqu’un d’autre peut représenter l’équipe. Une unique personne peut être nommée par l’équipe pour la représenter à chaque réunion Scrum of Scrums, ou bien le représentant peut changer au fil du temps, en fonction de qui peut remplir au mieux le rôle en raison des questions et circonstances actuelles. Chaque participant à la réunion devrait avoir la compréhension technique et être capable d’identifier des situations dans lesquelles les équipes pourraient causer obstacles ou retards les unes aux autres.

D’autres participants importants de réunion Scrum of Scrums incluent Scrum Master en chef et le Propriétaire de Produit en chef. Le but principal de la réunion Scrum of Scrums est de communiquer sur la progression entre des équipes multiples. Le Scrum Master en chef (ou n’importe quel Scrum Master qui faciliterait la réunion Scrum of Scrums), peut proposer un ordre du jour avant la réunion. Cela permet à chaque équipe de considérer les sujets de l’ordre du jour en préparant la réunion Scrum of Scrums.

De quoi discute-t-on ?

Tous les obstacles rencontrés par une équipe et qui peuvent aussi affecter d’autres équipes, devraient être remontés ainsi ils peuvent être discutés. De plus, si une équipe prend conscience d’un gros problème, changement ou risque qui peut impacter d’autres équipes, il devrait être communiqué lors de la réunion Scrum of Scrums.

Les productions des rétrospectives de Sprint peuvent aussi élever des problèmes qui pourraient impacter de multiples équipes Scrum et pourraient être utilisées lors de la réunion Scrum of Scrums. Ces réunions sont de préférence brèves (mais d’habitude non limitées dans le temps pour favoriser davantage d’échanges d’information entre les équipes) auxquelles se joint un représentant de chaque équipe Scrum pour partager le statut de son équipe. La réunion Scrum of Scrums se tient à intervalles prédéterminés ou quand demandé par des équipes Scrum. Ces réunions facilitent le partage en face-à-face d’informations entre des équipes Scrum différentes des difficultés, des dépendances et des risques qui doivent être étroitement contrôlés. Ceci aide les diverses équipes travaillant sur un grand projet à mieux coordonner et intégrer leur travail. C’est la responsabilité du Scrum Master en chef (ou tout autre Scrum Master qui facilite la réunion Scrum of Scrums) de s’assurer que tous les représentants ont un environnement contribuant à partager ouvertement et honnêtement l’information, y compris les réactions des représentants d’autres équipes. Pour de plus grands projets, impliquant un nombre significatif d’équipes, de multiples niveaux de ces réunions peuvent être implémentés. Chaque représentant d’équipe Scrum fournira à son tour les avancées de son équipe.

On donne d’habitude ces éléments en répondant à quatre questions spécifiques.

Sur quoi mon équipe a-t-elle travaillé depuis la dernière réunion ?
Que mon équipe fera-t-elle d’ici la prochaine réunion?
Quel reste-t-il à faire à mon équipe pour répondre aux attentes d’autres équipes ?
Que mon équipe va-t-elle faire qui pourrait impacter d’autres équipes ?

Les réponses à ces quatre questions fournissent l’information qui permet à chaque équipe de comprendre clairement le statut du travail de toutes les autres équipes. On recommande qu’une salle de réunion dédiée soit rendue disponible pour la réunion Scrum of Scrums, où tous les représentants d’équipes Scrum sont à l’aise.

Pour quels bénéfices ?

Dans le processus Scrum of Scrums, les meilleures pratiques pourraient être documentées sur la façon de conduire la réunion Scrum of Scrums et des suggestions incorporées dans le travail de projet d’équipes Scrum individuelles.

Il peut aussi y avoir une équipe d’experts du sujet qui peuvent aider le Scrum Master en chef à faciliter la réunion Scrum of Scrums.

L’une des productions importantes de la réunion Scrum of Scrums est la coordination du travail à travers des équipes Scrum multiples. C’est particulièrement important quand il y a des tâches avec des dépendances inter-équipes. Les incompatibilités et contradictions entre le travail et les livrables d’équipes différentes sont rapidement exposées.

Ce forum donne aussi aux équipes l’occasion de présenter leurs accomplissements et donner des retours à d’autres équipes.

En utilisant la réunion Scrum of Scrums, il y a de la collaboration à travers toute l’organisation par opposition à des personnes travaillant dans des équipes renfermées et concernées principalement par leurs responsabilités individuelles. La réunion Scrum of Scrums est un forum où les membres d’équipe Scrum ont l’occasion de discuter des problèmes impactant leur projet d’une manière transparente.

Le besoin de livrer chaque Sprint à l’heure force les équipes à confronter activement de telles questions au lieu de reporter à plus tard la recherche de résolution. Cette discussion et résolution opportunes de questions dans la réunion Scrum of Scrums améliorent énormément la coordination entre des équipes Scrum différentes et réduit aussi le besoin de refaire et retravailler. Les risques liés aux dépendances et délais de livraison sont aussi atténués.

Quelles sont les alternatives au Agile Planning Poker de Scrum ?

Le 1 août 20181 août 2018 par mopertodans agileLaisser un commentaire

Alternatives to Planning Poker

https://www.extremeuncertainty.com/alternatives-planning-poker/ de leontranter

Le Planning Poker est une façon commune de réaliser l’estimation des points d’histoire utilisateur. Il présente quelques avantages, mais aussi quelques problèmes.

Qu’est-ce que ce Planning Poker ?

Le Planning Poker est souvent utilisé dans des équipes Scrum (bien qu’il ne soit mentionné nulle part dans le guide Scrum selon la croyance populaire). Mike Cohn l’a popularisé dans son livre “Agile Estimating and Planning“. C’est une technique d’équipe pour collectivement estimer les points d’histoires d’utilisateur. (Pas sûr de ce que cela signifie ? Lisez le « guide to story point estimation »).

Si vous êtes déjà familiers du Planning Poker, n’hésitez pas à sauter directement plus bas “la planification d’alternatives au Planning Poker”. Sinon, continuez de lire pour une explication de comment cela fonctionne et pourquoi les gens l’utilisent.

Comment fonctionne-t-il ?

Disons que vous avez une équipe de sept ou huit personnes, qui ont environ une douzaine d’histoires d’utilisateur dans leur arriéré de produit qu’ils voudraient estimer. Pour le faire via le Planning Poker, chaque personne dans l’équipe aura une certaine méthode pour fournir un chiffre. C’est d’habitude via un sabot de cartes de poker, mais vous pourriez aussi utiliser une app sur votre téléphone. Les chiffres sont d’habitude des nombres de la suite de Fibonacci, une série où chaque nombre est la somme des deux nombres précédents. Donc cela donne 1, 2, 3, 5, 8, 13, 21, et cetera (on ne va d’habitude pas dépasser 21 parce que les histoires d’utilisateur ne devraient jamais être beaucoup plus grandes que d’autres).

L’équipe prend la première histoire de la liste et en discute un moment. Souvenez-vous, une histoire d’utilisateur est écrite comme une déclaration de problème. L’équipe réfléchit ensuite à combien de travail il faudrait pour répondre à cette déclaration de problème, c’est-à-dire mettre en œuvre une solution qui réalise le comportement décrit dans l’histoire.

Estimation de Planning Poker

Une fois que l’équipe est prête à estimer, chaque personne choisit un numéro de son jeu de cartes. Ils le font en silence. Puis, chaque personne révèle son évaluation en même temps.

La raison de procéder ainsi est que l’évaluation d’une personne ne devrait pas influencer l’évaluation d’une autre. Si chaque personne fournit son évaluation à son tour, la première personne pourrait choisir une grande (ou petite) estimation, qui pourrait faire changer d’avis d’autres personnes et ainsi biaiser leur évaluation. Le processus est destiné à permettre à chaque personne de fournir sa propre évaluation impartiale et honnête.

Bien sûr, les valeurs sont souvent différentes, ce qui signifie qu’une autre discussion démarre. Il y a parfois alors un autre round d’évaluation. Quelques puristes de Scrum insistent pour que l’équipe continue les rounds d’évaluation jusqu’à ce que chacun arrive au même nombre. Je pense que c’est de la folie et que cela encourage ce que le planning poker devrait empêcher : les gens « forçant » d’autres à être d’accord avec leur évaluation.

Je pense que cela devrait continuer jusqu’à ce qu’un consensus soit atteint, ce qui est d’habitude très clair (et PAS la même chose que la conformité, c’est-à-dire quand chacun a la même valeur). S’il y a une gamme d’évaluations consistant de 2, 2, 3, 3, 5, 5, l’estimation est de 3. Cela ne doit pas être une moyenne exacte, mais une médiane suffit. Et cela ne doit pas être mathématiquement précis. Les évaluations sont essentiellement des suppositions informées. Le processus d’évaluation n’est pas précis donc les évaluations ne le seront jamais et c’est ok.

Alors, pourquoi chercher des alternatives au Planning Poker?

Vous pourriez vous demander pourquoi vous voudriez des alternatives à le Planning Poker. Ce n’est pas un mauvais système, mais il a quelques problèmes.

Il est lent

Cela peut prendre une longue période de temps pour faire l’évaluation avec le Planning Poker. J’ai vu des sessions de deux ou trois heures et ce n’est pas amusant. Montrer ces cartes est au départ amusant mais cela devient usant vraiment rapidement. Tergiverser sur savoir si quelque chose vaut 2 ou 3 est ennuyeux et irritant et ce n’est pas une conversation de valeur.

Il distrait

La discussion sur quelle carte est bonne ou fausse peut distraire les gens d’une conversation de plus de valeur : la discussion de la solution. Particulièrement, pourquoi quelqu’un estime que quelque chose mérite 2 ou 3 par opposition à une autre valeur.

Il peut donner une fausse impression des estimations

Certaines personnes pensent que si vous faites ce jeu intelligemment, alors les évaluations elles-mêmes deviennent soudainement plus précises et donc de plus de valeur. C’est complètement faux. Le Planning Poker est une bonne façon d’atteindre un consensus sur des évaluations. Cela ne signifie pas qu’elles soient précises. Il est très possible pour un groupe de personnes d’être dans l’erreur à propos de quelque chose (particulièrement quelque chose de notoirement difficile à évaluer comme la complexité de développement de logiciel).

Les alternatives au Planning Poker

Il y a quelques alternatives que vous pouvez essayer si vous vous fatiguez du Planning Poker, ou pensez que cela pourrait être mieux.

Classement par taille de t-shirt

Au lieu des nombres (Fibonacci ou autres, vous pouvez utiliser des tailles de T-shirt. Petit, moyen, large, extra-large. Cela vous donne une plus petite gamme d’estimations possibles, ce qui signifie que vous obtiendrez moins de désaccords et moins de variance. Vous pourriez penser que les évaluations seront moins précises, mais je ne pense pas qu’elles le seront. Je constate que les tailles de t-shirt sont suffisantes. Vous aurez besoin de quelques références pour ces tailles; utilisez simplement des histoires ou des fonctions précédentes. (J’aime en réalité faire des évaluations de taille de t-shirt et aucune autre estimation d’histoire). Vous pourriez aussi utiliser un jeu plus réduit de nombres (1, 5, 8, 20) ou autre chose pour remplacer les tailles de t-shirt. Mais j’aime le fait que des nombres ne soient pas utilisés. Cela clarifie le fait que ce ne sont pas des mesures et elles ne sont pas précises.

Pour l’estimation précise, vous pouvez utiliser la technique du planning poker, ou la Technique « Affinity Mapping ».

Affinity Mapping

Vous pourriez être familiers avec la technique « Affinity Mapping » car elle est utilisée dans les Rétrospectives de Sprint. C’est une technique pour grouper ensemble des articles semblables. Commencez par créer une série d' »étiquettes » ou de « piles » sur la table : celles-ci pourraient être numérotés selon Fibonacci, ou les tailles de t-shirt, ou des catégories, ou quoi que ce soit. Puis, vous déposez les histoires sur la table comme des cartes. Ensuite, l’équipe déplace collectivement les cartes dans les piles pour les représenter selon leur estimation.

Petite Vidéo de Vincent Drecq, auteur du livre en français « Pratiques de management de projets ».

Classement silencieux par taille

C’est une technique intéressante, peu commune et peu connue. C’est une manière efficace d’évaluer un grand nombre d’histoires dans un espace de temps très court. Commencez par définir vos points de référence (nombres de Fibonacci, tailles de t-shirt, etc). Créez des piles sur la table selon la technique « Affinity Mapping ». Ensuite, chaque personne est aléatoirement assignée un jeu d’histoires à estimer (peut-être en distribuant les histoires comme si elles étaient des cartes à jouer). Puis, à tour de rôle, chaque personne évalue en silence en plaçant une carte sur une des piles. Alternativement, une personne peut déplacer une carte d’une pile à une autre, si elle est convaincue qu’une estimation est incorrecte.

Continuez à faire ceci jusqu’à ce que toutes les cartes soient estimées. Si une carte est déplacée deux fois, ôtez-la de la table – elle aura besoin d’une discussion séparée après la réunion car il y a un fort désaccord sur son estimation.

L’avantage de cette technique est qu’une équipe peut évaluer beaucoup d’histoires en un très court laps de temps. A utiliser si l’on vous demande d’évaluer 100 histoires (même si je pense que c’est le signe d’un plus gros problème car vous devriez seulement évaluer un ou deux sprints d’histoires Utilisateurs à l’avance). L’inconvénient est que vous sautez ce qui est souvent la partie de plus de valeur : la discussion autour des histoires.

Aucune évaluation

D’autres personnes prennent une position plus extrême. Ils pensent que nous devrions nous débarrasser totalement des estimations ! C’est un mouvement qui est souvent identifié par le hashtag Twitter #NoEstimates. Il a été lancé il y a quelques années par quelqu’un appelé Woody Zuil et est principalement soutenu par un coach Agile nommé Vasco Duarte. Si vous voulez l’essayer, c’est facile : n’abandonnez pas seulement le Planning Poker, abandonnez aussi toute estimation. Vous pouvez alors faire deux ou trois choses :

Donnez une évaluation moyenne sur toutes les histoires (utilisez une moyenne historique, total ou roulant la moyenne des trois derniers sprints)
Oubliez les points d’histoire et utilisez juste le nombre d’histoires pour la planification
Oubliez le planning d’histoires et estimez par fonctionnalité, utilisant probablement des tailles de t-shirt / le nombre de sprints.

En ce qui me concerne, je tombe dans le dernier camp. Je ne pense pas que les évaluations d’histoire sont très forte valeur, bien que des évaluations de haut niveau de fonctionnalités soient utiles pour la planification de release (et j’ai constaté qu’elles sont souvent aussi ou plus précises qu’une somme d’évaluations de point d’histoire).

#NoEstimates est un sujet complexe et très controversé et qui mérite une discussion séparée.

Conclusion

Vous pouvez essayer ces techniques et voir ce qu’en pense l’équipe. Assurez-vous de les considérer comme des expériences et recueillez-en les données: L’équipe estime-t-elle que c’est mieux que le planning poker ? Les évaluations se sont-elles avérées de plus de valeur ?

Rappelez-vous que la chose qui a le plus de valeur dans une session d’estimation est d’habitude les conversations autour de la solution, pas les nombres estimés.

« Dettes et mensonges sont ordinairement ensemble ralliés » Rabelais dans Pantagruel.

Using a « Technical Debt Register » in Scrum

Cela vaut cependant la peine de garder à l’esprit que pas tous les défauts et bugs ne constituent de la dette technique.

Il y a certain nombre d’autres contrôles qui peuvent être utilisés pour limiter la dette.

Ce que font certaines équipes est de maintenir un registre de dettes techniques

Que faire ?

Pour aller plus loin, relisez ces précédents billets sur ce sujet

partagez ce billet avec vos amis, collègues et relations professionnelles

S’adapter au monde numérique et disruptif ou bien disparaitre: Le quotidien des managers de projet…

Staying relevant as a Project Manager in today’s world

Pratiques Agiles et Lean

Avancement de carrière

partagez ce billet avec vos amis, collègues et relations professionnelles

Agile signifie accepter que votre projet ne livrera pas nécessairement tout qui a été spécifié au départ et que, en effet, les utilisateurs n’ont pas nécessairement besoin de tout ce qu’ils ont spécifié.

PRINCE2 Agile for PRINCE2® practitioners

L’approche Agile

Pourquoi le travail avec PRINCE2 Agile est-il efficace dans une organisation PRINCE2 ?

1. Une langue et une approche communes

2. Flexibilité avec les méthodes Agiles

3. Avoir une perspective business

4. L’Agilomètre

Pourquoi les praticiens PRINCE2 devraient-ils embrasser Agile?

partagez ce billet avec vos amis, collègues et relations professionnelles

“Nous ne sommes pas encore Agile, mais nous utilisons une approche hybride” ???

What is Hybrid Agile, Anyway?

Peut-être avez-vous entendu un dirigeant dire : “Nous ne sommes pas encore Agile, mais nous utilisons une approche hybride”.

« Itératif » par rapport à « Incrémental » par rapport à « Agile »

« Mélangé » (Blended) versus « Hybride »

Nous combinons des techniques adaptatives-agressives connues pour être meilleurs dans ce que nous faisons :

Mélangé = Agile + Agile = Meilleur Agile

Et bien, dans ces cas, vous devriez considérer « l’Hybride »

L’hybride = non-Agile + Agile = quelque chose entre les 2 qui a du sens

Quand devrions-nous utiliser des approches Hybrides ?

Voici deux scénarios :

1. Hybride comme Adéquat en fonction du but

2. Hybride comme Transition-vers-Agile

partagez ce billet avec vos amis, collègues et relations professionnelles

WSJF est utilisé pour séquencer les travaux dans l’optique de générer un bénéfice maximal: Fonctionnalités, Epics et User Stories Scrum.

Ce « coût du retard » est la somme de trois estimations :

WSJF est donc utilisé pour prioriser l’arriéré de produit en calculant le coût du retard par rapport à la taille de la tâche (à défaut de durée).

Deux vidéos pour aller un peu ou beaucoup plus loin (en 3 et 20 minutes)

2 pages utiles

C’est dans la comparaison relative des WSJF des différents items de l’arriéré de produit et dans la transparence de la priorisation que réside la force de cette technique.

partagez ce billet avec vos amis, collègues et relations professionnelles

Voici 2 vidéos et 3 billets que j’ai trouvés intéressants sur ce sujet qui se trouve au cœur même de l’agilité.

Retrouvez ces billets précédemment publiés sur DantotsuPM.com

partagez ce billet avec vos amis, collègues et relations professionnelles

Bien prioriser les items dans l’arriéré de produit est l’une des difficultés que nous rencontrons très souvent.

A technique to help Prioritise your Backlog

En tant que Propriétaire de Produit (« Product Owner ») pensez-vous jamais que …. ?

Le schéma ci-dessous montre une façon de représenter tout le travail possible sur 2 axes : le temps et qui le travail aide le plus.

Passé et Business (Support)

Futur et Business (Nouveau Business)

Passé et Technique (Dette Technique)

Futur et Technique (Innovation Architecturale)

Et ci cela pouvait aussi s’avérer utile comme approche générique pour prioriser un portefeuille de projets ?

C’est une technique que nous utilisons dans notre livre “Growing Agile: A Coach’s Guide to Mastering Backlogs”.

partagez ce billet avec vos amis, collègues et relations professionnelles

Le Planning Poker® peut paraitre complexe pour ceux qui deviennent juste de commencer à l’utiliser.

Tips for Playing Planning Poker

Règles de base

Conseils et suggestions

Tenez vos mises cachées jusqu’à ce qu’il soit temps de jouer.

Pour aller plus loin

partagez ce billet avec vos amis, collègues et relations professionnelles

De trop nombreuses organisations ont du mal ou même échouent purement et simplement à mettre en œuvre des structures pour accroitre leur niveau d’agilité.

Chaque personne est une activatrice de changement, encouragée et autorisée à faciliter cette évolution.

Les cinq principes

Les cinq pratiques

Le comment (correspond à l’approche de livraison AgileSHIFT)

Il y a 3 rôles : l’équipe AgileSHIFT, le sponsor et le coach.

Pour montrer votre compréhension d’AgileSHIFT, une certification basique et de praticien seront possibles.

Pour aller plus loin, un wébinaire en langue anglaise est proposé par Axelos

partagez ce billet avec vos amis, collègues et relations professionnelles

Pour des organisations tenant à adopter une nouvelle façon de travailler, voici cinq étapes clefs pour inspirer une transformation vraiment saine et Agile

Agile How to increase your company’s metabolism

encore une autre expression à la mode ?

Qu’est-ce que le métabolisme organisationnel ?

Travailler plus intelligemment

1. Maintenez une vision claire et inspirante

Le Planning Poker^® peut paraitre complexe pour ceux qui deviennent juste de commencer à l’utiliser.

Le business au 21^ème siècle