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

« 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.

finiNotez 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.

remboursez graduellement votre dette

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.

CertYou est partenaire de DantotsuPM

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 ?

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

 

Livres sur Amazon

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.

CertYou est partenaire de DantotsuPM

Avancement de carrière

accessible sur le site web du PMI

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.

Pour tous les détails (en anglais)

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®

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

Livre su Amazon

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.

CertYou est partenaire de DantotsuPM

 

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

“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.

CertYou est partenaire de DantotsuPM

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

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 :

  1. la valeur pour le business et les utilisateurs,
  2. la criticité temporelle et
  3. 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

CertYou est partenaire de DantotsuPM

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)

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

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.
Livre sur Amazon

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)

résultatsCe 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 ?

SMPP est Partenaire de DantotsuPM

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

  1. Vous ne pouvez pas être 100 % précis, n’y passez donc pas trop de temps. Personne ne connait l’avenir avec précision.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. Ne reprenez pas ni réparez vos évaluations qui étaient fausses. Vos erreurs entreront dans la moyenne après quelque temps.
  7. 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.
  8. 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.

CertYou est partenaire de DantotsuPM

Pour aller plus loin

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

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

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

Les cinq pratiques

  1. Planifiez d’être flexible et adaptable
  2. Engagez avec les parties prenantes
  3. Construisez des équipes collaboratives
  4. Concentrez-vous sur la co-création de valeur
  5. 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®

CertYou est partenaire de DantotsuPM

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

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’.

CertYou est partenaire de DantotsuPM

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

générer de la valeurDans 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.

aider les personnes à élever leur niveauIls 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

une image claire de sa raison d’être et du résultat visé

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.