Il y a fréquemment de grands débats sur l’utilisation de la suite de Fibonacci pour estimer des histoires d’utilisateur. L’estimation est au mieux un outil imparfait, mais un outil nécessaire pour planifier le travail.
L’estimation d’histoire d’utilisateur est basée sur la recherche du Ministère de la Défense américaine en 1948 qui a développé la technique Delphi. La technique a été classifiée jusqu’aux années 1960 (il y a des douzaines de papiers sur le sujet sur rand.org). Essentiellement, les chercheurs de Rand ont voulu éviter la pression vers la conformité de groupe qui menait typiquement à de mauvaises évaluations. Donc, ils ont décidé que les estimations devaient être faites dans le secret. Initialement, les évaluations seraient très éloignées parce que les gens auraient des perceptions différentes du problème donc ils les feraient parler des maximums et des minimums proposés après l’estimation en secret, puis estimer ensuite dans le secret de nouveau. Sur Rand Worldwide vous pouvez lire les papiers originaux qui démontrent de la convergence.
Les chercheurs de Rand ont alors étudié l’effet des choix de nombres parmi lesquels choisir et ont constaté qu’un ordre linéaire donnait de plus mauvaises évaluations qu’un jeu de nombres augmentant exponentiellement. Il y a quelques arguments mathématiques récents pour ceux qui sont intéressés. La question, si vous voulez la meilleure évaluation statistiquement prouvable, est alors quelle série d’augmentation exponentielle utiliser. La suite de Fibonacci est presque, mais pas tout à fait exponentielle et a l’avantage que c’est le modèle de croissance vu dans tous les systèmes organiques. Pourquoi la suite de Fibonacci se répète-t-elle dans la nature ? Donc, les gens sont très familiers avec elle et l’utilisent constamment dans le choix des tailles de vêtements. Par exemple, les tailles de T-Shirt suivent Fibonacci. Puisque quelques développeurs sont opposés aux nombres (un phénomène vraiment étrange pour ceux qui travaillent avec des ordinateurs), ils peuvent utiliser des tailles de T-Shirts et leurs évaluations sont facilement traduites en chiffres.
Microsoft a répété cette recherche ces dernières années et publié un papier primé par l’IEEE. En conséquence, Microsoft a abandonné les estimations horaires des projets. Voir le papier récompensé en 2011 par IEEE de Laurie Williams, Gabe Brown, Adam Meltzer, Nachiappan Nagappan (2012) Scrum + Engineering Practices: Experiences of Three Microsoft Teams.
Donc la communauté Agile a convergé sur Fibonacci comme la suite de nombres à utiliser. Malheureusement, beaucoup d’équipes agiles ne l’utilisent pas correctement et essayent de faire chacun converger sur un nombre de Fibonacci, ce qui vous donne mathématiquement et par expérience de mauvaises évaluations à cause du biais de conformité au groupe. C’est exactement ce que les chercheurs de Rand ont cherché à éviter en inventant la Technique Delphi.
À maintes reprises, les chercheurs ont montré que les estimations en heures ont de très forts taux d’erreur. C’est vrai même si l’utilisateur est un expert. C’est l’outil qui est le problème. Si vous voulez pratiquer en vous basant sur les évidences, des évaluations de taille relatives livrent tout simplement une estimation beaucoup plus précise.
CertYou est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Marche rationnelle de l’esprit pour arriver à la connaissance ou à la démonstration d’une vérité
Ensemble ordonné de manière logique de principes, de règles, d’étapes, qui constitue un moyen pour parvenir à un résultat
Manière de mener, selon une démarche raisonnée, une action, un travail, une activité
Ensemble des règles qui permettent l’apprentissage d’une technique, d’une science
Livre blanc de notre partenaire QRP International
Avis personnel
tout le monde a le droit de partager mon opinion 🙂
Si je considère que, dans le management de projet, Agile relève en grande partie de la souplesse, de la flexibilité, de la rapidité, de la proximité avec l’utilisateur final…
Alors, Agile est une approche car Agile est avant tout une manière d’aborder le projet, d’adresser et de répondre aux problèmes majeurs des clients et utilisateurs.
Et, Agile est aussi une méthode qui propose différentes démarches rationnelles avec des étapes ordonnées de manière logique, des principes et des règles ainsi que de l’action.
Qu’en pensez-vous : Approche ou Méthode ?
partagez ce billet avec vos amis, collègues et relations professionnelles
Gageons que la certification PMI Agile Certified Practitioner (PMI-ACP)® va encore séduire davantage de managers de projet !
PMGS est partenaire de DantotsuPM
En effet, en Avril 2019, il deviendra possible de passer l’examen en ligne, depuis votre bureau ou de chez vous.
Le mouvement Agile est devenu un standard au fil des années comme approche de management de projet et cette certification permet aux managers de projets de s’acculturer aux différentes méthodes et états d’esprit associés à l’agilité.
Aussi, les statistiques de janvier dernier du PMI indiquent-elles que le nombre de certifiés PMI-ACP a atteint plus de 26000 professionnels en quelques années alors que la certification CAPM qui qualifie les débutants dans le métiers de management de projet en est à 37000 après bien plus longtemps. Il est vrai aussi que nombre de certifiés CAPM seront devenus des professionnels du management de projet et auront passé d’autres certifications après avoir obtenu l’expérience requise. Certains auront évolué vers d’autres rôles ou métiers dans lesquels leur culture projet leur restera toujours utile !
“PMI,” “CAPM,” and “PMI-ACP” are registered marks of Project Management Institute, Inc.
partagez ce billet avec vos amis, collègues et relations professionnelles
Demandez votre copie gratuite de ce très sympathique et complet poster Scrum et montrez-le à vos collègues et amis.
Cette affiche peut être un outil d’apprentissage (par exemple lors de la lecture du guide Scrum) et un outil permettant à un ScrumMaster d’expliquer Scrum à l’organisation, au responsable produit ou à l’équipe de développement.
Une seule demande par personne est acceptée. Expédition aux États-Unis et en Europe uniquement. Vous serez informés par e-mail une fois le poster expédié.
CertYou est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Une responsabilité clef des « Product Owners » / Propriétaires de Produit est de s’assurer que la priorisation des articles de travail dans un arriéré de produit réalise au mieux les buts et la vision pour le produit. À la différence des portefeuilles de projet où les choix ou décisions de priorisation sont souvent prises par un comité de direction, avec un arriéré de produit, la responsabilité de la réussite business ou de l’échec du produit repose sur les épaules du Propriétaire de Produit.
Cette activité tient autant de la science que de l’art.
On doit prendre en compte de multiples facteurs en compétition et trouver un équilibre
Valeur d’affaires
Alignement avec la vision originale
Dépendances
Contraintes
Réduction de risque
L’évaluation du coût de retard ou du Weighted Shortest Job First (Travail Pondéré le Plus court en Premier) peut injecter cohérence et objectivité dans l’activité, mais cela demande aussi beaucoup d’apprentissage et d’efforts. Si bien utilisé, de telles approches d’évaluation devraient être utilisées pour guider le processus décisionnel plutôt que le remplacer.
Relisez ce billet sur le Weighted Shortest Job First
Le Propriétaire de Produit doit collaborer efficacement avec les parties prenantes clefs pour valider que les livrables ne satisferont pas seulement les besoins des uns ou des autres. Cette collaboration exige une volonté de la part du Propriétaire de Produit de reculer la sortie de certaines fonctions « très très demandées » si cela aboutira à un meilleur produit d’ensemble.
Quand il travaille avec une nouvelle équipe, le Propriétaire de Produit doit activement écouter pendant les discussions de revue de l’arriéré avec les membres d’équipe car certains pourraient manquer du courage d’ouvertement défier une décision peu éclairée. Une façon d’aider à surmonter ce risque est de demander activement à l’équipe au fur et à mesure que les articles sont classés s’ils voient des défauts dans l’ordonnancement ou s’ils pensent qu’un article pourrait devoir être abordé plus tôt. La priorisation peut être un bon sujet à considérer pendant des rétrospectives afin d’inspecter et adapter régulièrement le processus.
différentes perspectives
Le Propriétaire de Produit voudra naturellement maximiser l’obtention de valeur business tandis que les propriétaires de solution voudront aborder des incertitudes sur la solution ou adresser l’adaptabilité ou la flexibilité dès le début. Une saine priorisation devrait ressembler à une lutte à la corde entre les représentants pour chaque facteur d’influence.
Un bon Propriétaire de Produit devrait mettre son ego de côté lors de l’activité de priorisation car son but n’est pas de démontrer son omniscience sur le séquencement du développement du produit, mais plutôt de livrer le meilleur produit possible.
SMPP est Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Un des principes Agiles est : “la méthode la plus efficace et efficiente de transmettre l’information dans une équipe de développement est la conversation en face à face.”
Ceci est utilisé pris par la plupart des agilistes comme la justification pour des équipes géographiquement co-localisées. Il y a eu bien des débats autour de la possibilité d’avoir des équipes géographiquement distribuées et comment cela fonctionnerait dans un environnement Agile et plus spécifiquement Scrum. Vous pouvez lire de très forts avis pour ou contre.
Le manifeste agile exprime clairement “S’adapter au changement PLUS que suivre d’un plan” et c’est probablement ce qui devrait être fait ici.
La manière dont les équipes travaillent change constamment et les équipes géographiquement distribuées sont une réalité dans un monde globalisé. Vous avez tous les jours des ScrumMasters aux États-Unis avec des équipes de développement en Chine ou en Inde. Cela ne peut être ignoré. Ce qui peut être fait est de suivre l’esprit du Manifeste Agile qui considère la conversation en « face à face » comme la plus efficace. De nos jours, il y a tant d’outils à notre disposition qui peuvent donner une expérience de conversation en face à face même quand les équipes sont à des milliers de kilomètres de distance. En dehors des outils, il y a peu d’indications pour aider à coordonner efficacement le travail de ces équipes.
1. Les réunions Scrum
Une fois que l’équipe est prête à fonctionner en virtuel, il est essentiel que toutes les réunions recommandées par l’approche Scrum se passent dans la réalité comme prévues. Cela inclut par exemple un Daily Stand-up mais à distance. On peut utiliser des outils comme Skype ou d’autres outils de conférences sur internet (Webex ou GotoMeeting) pour suivre ces réunions. Ces réunions peuvent aussi servir de sessions de « team building » dans une équipe multiculturelle et multilingue. Le ScrumMaster doit prendre les devants et s’assurer que tous les membres d’équipe suivent ces réunions et participent comme exigé.
2. La communication
Les équipes Scrum distribuées géographiquement dans le monde entier peuvent varier en termes d’éthique de travail, de culture de bureau et de langue. Donc une plate-forme et une langue communes sont exigées pour manager les différences. Les facteurs comme des fuseaux horaires différents, des horaires de travail et le mode de communication devraient être clairement identifiés pour aider à mettre en place des canaux de communication clairs et transparents.
3. Co localisation
Il faut trouver des opportunités de réunir les équipes géographiquement et culturellement distribuées
Parfois quand le travail est proche de se terminer ou si le projet exige qu’une ou plusieurs équipes travaillent étroitement ensemble, les équipes pourraient devoir se rassembler temporairement en un même endroit. Cela aide dans la construction de l’esprit d’équipe quand les membres d’équipe parviennent à se connaître et ce augmente l’efficacité dans la livraison du projet.
Avec la globalisation, l’évolution vers des équipes Scrum géographiquement distribuées et travaillant dans un environnement virtuel est un changement inévitable et aussi un complément à la façon dont nous livrons des projets avec Scrum.
CertYou est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
La première équipe de Scrum a fini son premier Sprint il y a 25 ans. Mon but alors et il continue de l’être, était de construire des équipes à hautes performances. Depuis, je me suis concentré uniquement sur ce sujet. Comment permettons-nous aux gens d’en accomplir davantage, de vivre de meilleures vies et de changer fondamentalement la trajectoire de leur réussite ?
Des millions des gens se rencontrent généralement maintenant chaque jour pour leur Daily Scrum.
Il est stupéfiant de voir comment Scrum a réorganisé le monde de travail au travers de nombreuses disciplines et au-delà du logiciel. The Standish Group data montre que des projets Agiles ont trois fois moins de chance de complètement échouer que des projets en cascade et quatre fois plus de chance de réussir. C’est ce qui fait que les sociétés veulent devenir « Agile ».
Actuellement, la menace existentielle sur Scrum est le “Mauvais Scrum (Bad Scrum).” Donc, j’ai investi ces quelques dernières années à codifier les meilleures pratiques pour faire grandir Scrum et réfléchir à ce qui fonctionne ou pas et y donner un nom : Scrum@Scale.
Scrum@Scale est la structure pour que les organisations développent itérativement la meilleure façon pour Scrum de marcher dans leur contexte.
téléchargez gratuitement le guide complet de 19 pages
Donc je l’ai gardé simple. Le Guide Scrum@Scale comporte juste quelques pages. Comme avec Scrum et le Guide Scrum, il est libre d’accès. Vous ne devez pas me demander la permission. Prenez-le, utilisez-le et partagez votre connaissance et votre expérience.
Chaque équipe Scrum est différente, même des équipes dans la même organisation. Elles ont leur culture propre, leurs façons de travailler, des succès, des échecs, leur propre contexte. Mais elles suivent une structure commune. Et dans cette structure elles développent itérativement de nouvelles solutions aux problèmes qu’elles essayent de résoudre.
Pour disséminer le bon Scrum et avoir l’impact nous voulons avoir sur le travail, nous avons besoin de plus de personnes que seulement Scrum Inc. pour l’enseigner. Nous avions un pilote l’année dernière avec Angela Johnson de l’Équipe Co-Lead et avons énormément appris. Nous postons ses formations sur le site Web de Scrum Inc aussi bien que scrumatscale.com. L’an dernier, nous avons décerné un diplôme à notre première classe de formateurs Scrum@Scale. Ils étaient 17.
Vous pouvez lire le processus pour devenir formateur avec toutes les qualifications et bénéfices sur notre site scrumatscale.com.
Je veux vraiment mettre en évidence une chose que nous exigeons vraiment . Pour devenir un formateur Scrum@Scalevous devez avoir implémenté Scrum à l’échelle et soumis une étude de cas de ce travail. Qu’avez-vous appris ? Qu’est-ce qui était difficile ? Qu’est-ce qui a fonctionné ? Et cette étude de cas doit être partagée. Pas juste avec Scrum Inc. Pas seulement avec d’autres formateurs Scrum@Scale. Avec le monde entier. Nous voulons que le monde entende parler des réussites de nos formateurs et que ces histoires deviennent des points de référence dans une conversation globale.
Des centaines de personnes ont déjà suivi nos classes Scrum@Scale, beaucoup de coachs et formateurs. Les réactions que nous avons obtenues sont que c’est une codification des meilleures pratiques qu’ils avaient appliquées depuis des années. Nous voulons favoriser une communauté où les gens et les organisations se transforment en apprenant les uns des autres.
Nous voulons créer une bibliothèque vivante des innombrables manières d’utiliser Scrum à l’échelle dans une structure commune.
Jeff Sutherland, Creator of SCRUM
Une bibliothèque qui est là si vous êtes l’une des sociétés du Fortune 100 aux États-Unis ou une startup en pleine croissance à Hyderabad.
Comme vous le savez peut-être, je me suis retiré du poste de CEO de Scrum Inc en janvier 2018. Une des raisons principales est qu’ainsi je pourrai concentrer mes efforts sur Scrum@Scale et le partager avec autant de personnes que possible dont les vies seront meilleures grâce à cela.
Avez-vous déjà utilisé ce guide et quels sont vos retours personnels ?
CertYou est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
C’est en 2017, que « Age of Product » a lancé le premier rapport sur les salaires des Scrum Masters.
Le tout premier rapport de l’industrie qui regardait en profondeur les antécédents scolaires, l’expérience au travail, les industries et les détails organisationnels des entreprises pour lesquels travaillent les Scrum Masters ou coaches Agile.
L’édition 2019 du Scrum Master Trends Report a été créée en partenariat avec Scrum.org, le principal établissement de formation et de certification Scrum fondé par Ken Schwaber, cofondateur de Scrum.
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.
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
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.
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é.
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?
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
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
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.
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)
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.
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é.
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
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.
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.
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 ?
partagez ce billet avec vos amis, collègues et relations professionnelles
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)
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 ?
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.
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.
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
Pour des organisations tenant à adopter une nouvelle façon de travailler, voici cinq étapes clefs pour inspirer une transformation vraiment saine et Agile
‘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 ?
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
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.
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
partagez ce billet avec vos amis, collègues et relations professionnelles
Pas de surprise côté méthodes, SCRUMreste 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.
Les chercheurs de Rand ont alors étudié l’effet des choix de nombres parmi lesquels choisir et ont constaté qu’un ordre linéaire donnait de plus mauvaises évaluations qu’un jeu de nombres augmentant exponentiellement. Il y a quelques arguments mathématiques récents pour ceux qui sont intéressés. La question, si vous voulez la meilleure évaluation statistiquement prouvable, est alors quelle série d’augmentation exponentielle utiliser. La suite de Fibonacci est presque, mais pas tout à fait exponentielle et a l’avantage que c’est le modèle de croissance vu dans tous les systèmes organiques. Pourquoi la suite de Fibonacci se répète-t-elle dans la nature ? Donc, les gens sont très familiers avec elle et l’utilisent constamment dans le choix des tailles de vêtements. Par exemple, les tailles de T-Shirt suivent Fibonacci. Puisque quelques développeurs sont opposés aux nombres (un phénomène vraiment étrange pour ceux qui travaillent avec des ordinateurs), ils peuvent utiliser des tailles de T-Shirts et leurs évaluations sont facilement traduites en chiffres.
DantotsuPM.com 