Comment faciliter les conversations difficiles de l’équipe Scrum ?

Le 21 mars 202312 mars 2023 par mopertodans agile, outils et méthodes, pointeurs utilesLaisser un commentaire

Être un Scrum Master ou un membre de l’équipe efficace implique inévitablement d’avoir des conversations difficiles.

How to Facilitate Difficult Scrum Team Conversations par Stephanie Ockerman

https://www.scrum.org/resources/blog/how-facilitate-difficult-scrum-team-conversations

Être un Scrum Master ou un membre de l’équipe efficace implique inévitablement d’avoir des conversations difficiles. La façon dont nous abordons les discussions difficiles peut faire la différence entre un moment de transformation et un déraillement. Heureusement, nous pouvons faire beaucoup pour nous préparer à ces moments où nous devons nous débattre d’une question épineuse. Examinons quelques stratégies pour faciliter les conversations difficiles de l’équipe Scrum.

Sujets sensibles et fort niveau émotionnel

Les conversations difficiles impliquent des niveaux élevés d’anxiété, d’inquiétude ou de doute. Peut-être devons-nous prendre une décision difficile ou trouver comment faire quelque chose que nous n’avons jamais réalisé auparavant. Peut-être qu’il y a un conflit entre les membres de l’équipe, ou qu’il y a eu un échec important ou bien un Sprint exceptionnellement difficile. Peut-être que les parties prenantes ne sont pas satisfaites des progrès ou ont des opinions divergentes sur l’orientation du produit ou sur la façon d’interpréter les changements sur le marché. Il existe une myriade d’exemples de circonstances à enjeux élevés auxquelles les équipes Scrum sont régulièrement confrontées et qui nécessiteront des conversations difficiles. Alors, comment pouvons-nous traverser ces périodes avec succès ?

CSP DOCENDI est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.

Respirez et préparez-vous

L’un des faux pas les plus courants que nous faisons face à une conversation difficile est d’être réactif et de sauter directement sur une tentative pour « résoudre » le problème.

Mais une facilitation réussie implique de prendre le temps de vous familiariser avec la situation et de décider comment vous allez l’aborder.

Idéalement, vous serez en mesure de prendre suffisamment de temps pour vous préparer en toute confiance. Mais même dans les situations où une situation difficile a émergé, vous pouvez souvent faire une brève pause pour vous recentrer. Laisser le temps à la conversation de se dérouler avant de vous lancer vous aidera à comprendre les problèmes. Vous pourriez avoir besoin de proposer une ou plusieurs sessions de travail pour permettre aux gens d’analyser des idées et des options avant de vous réunir.

Définissez l’intention

Le fait d’être clair sur l’objectif de la conversation apporte de la clarté au processus de facilitation. Tout le monde autour de la table devrait savoir pourquoi ils sont là et quelles sont les attentes.

Êtes-vous réunis pour chercher à comprendre le point de vue de chacun ? Allez-vous réfléchir ensemble à des solutions ou parvenir à un consensus sur les idées déjà sur la table ? Devez-vous en équipe réparer les relations interpersonnelles ou créer une identité d’équipe plus claire ? Avoir une idée claire de l’objectif de se réunir réduit l’anxiété et maintient la conversation centrée et productive.

Soyez inclusif

Familiarisez-vous avec la gamme de techniques et activités de facilitation adaptées à différentes personnalités et attitudes. Certaines personnes préfèrent faire un remue-méninge par elles-mêmes avant de partager des idées en groupe. D’autres préfèrent interagir en petits groupes ou partager leurs pensées par écrit plutôt que verbalement. Les techniques impliquant la visualisation, les métaphores et autres outils créatifs peuvent également mieux convenir à certaines équipes. Vous aurez probablement besoin de combiner ces techniques et outils.

Comprendre la dynamique de notre équipe et présenter les options aidera à faire en sorte que tout le monde se sente aussi à l’aise que possible pour s’engager.

Soyez présent

Les facilitateurs efficaces sont à l’écoute de ce qui se passe pendant la conversation en :

Écoutant activement (vous vérifiez avec l’orateur pour vous assurer que vous avez compris ou pour clarifier).
Lisant les messages non exprimés, telles que « se déconnecter » en regardant son smartphone ou d’autres indices.
Remarquant des interactions entre les membres de l’équipe qui pourraient révéler une dynamique tacite en action.

Être conscient et présent vous permet de détecter la direction de la conversation et de faire des choix éclairés dans l’instant.

Soyez flexible

Bien que vous deviez être intentionnel et prêt à faciliter, vous devez également vous adapter à ce qui se passe devant vous. Comme tous les agilistes le savent, les choses ne se déroulent pas toujours comme prévu, il est donc préférable de ne pas trop vous attacher à votre agenda ou à des structures de facilitation spécifiques.

Ralentissez

Il est très facile dans les situations de forte émotion de passer en mode réactif, ce qui réduit votre capacité à rester ouvert, flexible et créatif. Vous voulez éviter une réaction instinctive à ce que vous entendez ou expérimentez pour diriger la situation de manière réfléchie. Vous pouvez en apprendre plus sur cette dynamique dans ce précédent article Staying Creative in a Reactive World.

Prendre conscience de la façon dont vous réagissez pendant les périodes stressantes peut vous aider à rester calme et à changer de cap si nécessaire. Une première étape utile consiste simplement à ralentir les choses lorsque le stress du moment vous incite à les accélérer. Ce n’est pas aussi facile qu’il n’y paraît. Les anglophones nord-américains deviennent typiquement mal à l’aise avec des pauses de plus de quelques secondes dans les conversations. Il faut de la pratique.

Faire des pauses régulières pour traiter l’information améliore la compréhension et vous permet de répondre avec curiosité et ouverture. Alors, respirez et encouragez les autres membres de votre équipe à faire de même. Prendre des pauses fréquentes permet également aux membres de votre équipe qui pourraient avoir besoin de plus de temps pour traiter les informations de s’engager plus facilement. Il permet à chacun de prendre de meilleures décisions, plus éclairées.

Reconnaissez également que certaines situations et décisions nécessitent plus de temps que d’autres. Nous avons tendance à avoir un faux sentiment d’urgence dans nos organisations, mais souvent nous pouvons retarder un peu les décisions quand nous devons prolonger la conversation ou recueillir plus d’informations. L’expression « Prenez des décisions au dernier moment raisonnable » me vient à l’esprit.

Notez que je ne préconise pas d’étendre les durées des événements Scrum. Si les problèmes que vous devez traiter nécessitent plus de temps, il est préférable de déplacer ces discussions en dehors de l’événement.

Cultivez un « espace courageux »

Faciliter une conversation difficile avec succès nécessite une sécurité psychologique pour les participants. Les membres de l’équipe doivent savoir qu’ils ne seront pas punis ni humiliés pour avoir dit ce qu’ils pensaient et suggéré des idées. Mais gardez à l’esprit qu’un espace « sûr » ne signifie pas nécessairement être parfaitement à l’aise. Les membres de l’équipe vont éprouver des sentiments inconfortables en discutant de questions épineuses.

Je promeut plutôt l’idée d’un « espace courageux ». Dans un espace courageux, nous sommes prêts à être vulnérables. Nous sommes ouverts aux commentaires difficiles de nos collègues. Nous nous engageons à apprendre.

Les compétences en animation sont pour tout le monde

L’amélioration des compétences en animation n’est pas réservée aux Scrum Masters. Tout membre de l’équipe Scrum peut animer des événements et des sessions de travail. Les compétences en facilitation sont précieuses pour de nombreux problèmes qui surviennent dans votre vie professionnelle quotidienne, et lorsque chaque membre de l’équipe Scrum se sent à l’aise avec la facilitation, toute l’équipe en bénéficie.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Conclusion

Il existe de nombreuses techniques de facilitation créatives et intéressantes disponibles en ligne. Mais il est essentiel que vous soyez intentionnel quant aux techniques que vous sélectionnez, comment vous les combinez et comment vous choisissez de répondre dans l’instant en ce qui concerne la direction de ce qui émerge au cours de nos conversations.

C’est pourquoi j’apprécie la formation Professional Scrum Facilitation Skills (PSFS). Tout comme « there are no best practices in Scrum”, il n’a pas de meilleures techniques de facilitation. Ce cours vise à vous aider à développer l’état d’esprit d’un facilitateur, en apprenant à sélectionner des techniques efficaces pour différentes situations dans votre contexte.

Petit rappel: Développez la productivité et l’innovation avec des groupes de toutes tailles grâce aux Liberating Structures !

Voici un pointeur fort utile vers des méthodes (et une app pour votre mobile) pour vous aider à impliquer tout le monde lors de vos sessions de travail de groupe.

Téléchargez l’app LISA sur votre smartphone IOS ou Android. C’est gratuit, très intéressant et fort utile !

Améliorez la culture organisationnelle grâce à la reconnaissance pendant les rétrospectives.

Le 20 mars 202311 mars 2023 par mopertodans agile, experience sharingLaisser un commentaire

Les rétrospectives présentent de belles opportunités pour les membres de l’équipe de reconnaitre d’une manière authentique et sincère les efforts des autres personnes au cours du sprint passé.

Improving organizational culture through retrospective recognition par Kiron Bondale

https://kbondale.wordpress.com/2018/11/25/improving-organizational-culture-through-retrospective-recognition/

Après avoir observé les acheteurs frénétiques en compétition les uns avec les autres lors des ventes du Black Friday à l’automne dernier, on pourrait être tenté d’oublier que Thanksgiving était à l’origine une expression de gratitude.

Le Guide Scrum n’identifie pas spécifiquement l’expression d’appréciations comme un ingrédient clé des rétrospectives de sprint, mais il énumère les activités qui peuvent intégrer l’appréciation telles que l’inspection des interactions des membres de l’équipe et le rôle du Scrum Master pour encourager l’équipe non seulement à être plus efficace, mais aussi à passer un moment plus agréable ensemble au prochain sprint.

Les animateurs de rétrospectives encouragent souvent les participants à identifier ce qui s’est bien passé ou ce qu’ils ont aimé. C’est une bonne opportunité pour les membres de l’équipe de reconnaitre d’une manière authentique et sincère les efforts des autres personnes au cours du sprint passé.

Remercier pour l’aide reçue pour franchir un obstacle signifie aussi que vous seriez prêt à aider à votre tour.

Tout comme l’identification des possibilités d’amélioration, les membres de l’équipe doivent non seulement reconnaître les grandes réalisations, mais aussi les petites qui peuvent s’additionner au fil du temps. Nous sommes prompts à reconnaître un membre de l’équipe qui a laissé tomber ce qu’il faisait pour nous aider pendant quelques heures sur une question vraiment délicate, mais qu’en est-il de ce membre de l’équipe qui nous a emmenés prendre un café parce qu’il a remarqué que nous semblions être particulièrement stressés ce jour-là ?

Tout comme pour fournir des commentaires constructifs, nous ne devrions pas attendre une prochaine rétrospective pour nous remercier, mais la cérémonie de rétrospective offre une bonne occasion de remercier tardivement ceux dont les efforts ont fait la différence au cours du sprint passé. Un Scrum Master peut introduire cette pratique dans une rétrospective en utilisant des chocolats ou tout autre petit cadeau à offrir par les membres de l’équipe à ceux qu’ils souhaitent reconnaître. Dans les rétrospectives ultérieures, l’équipe peut identifier de nouvelles façons de faire pour garder la pratique vivante.

Un récent article du Washington Post décrit comment la gentillesse peut être contagieuse.

Toute personne qui a participé ou initié une chaîne de « paiement en avance » serait probablement d’accord avec l’auteur de l’article. Lorsque quelqu’un apprécie de vive voix ce que nous faisons, nous ressentons le besoin de faire de même. Exprimer régulièrement vos sentiments positifs pourrait améliorer progressivement la culture au sein de vos équipes, de vos départements et, éventuellement, de votre organisation globale.

Votre projet est-il adapté aux pratiques agiles ?

Le 22 février 202319 février 2023 par mopertodans agile, outils et méthodes1 commentaire

Tous les projets ne sont pas adaptés aux approches agiles. Des critères bien pensés peuvent vous aider à déterminer si vos projets sont de bons candidats agiles.

Is your project suitable for agile practices? par Bonnie Biafore

http://www.bonniebiafore.com/is-your-project-suitable-for-agile-practices/

Voici des questions que vous pouvez utiliser pour développer vos propres critères de qualification pour Agile :

Pouvez-vous obtenir le bon personnel ?

Les membres appropriés de l’équipe technique et métier doivent être dédiés au projet. Cela signifie que vous devez gérer les compromis difficiles entre le travail de projet et les considérations opérationnelles. Les projets agiles produisent des résultats rapidement, ils prennent donc beaucoup de temps aux participants. De plus, les approches agiles nécessitent des membres essentiels des équipes business et technique qui sont critiques à vos activités opérationnelles. Il est important de prioriser leur temps sur le projet afin qu’ils puissent contribuer efficacement.

Les ressources ont-elles une profondeur de connaissances appropriée ?

Une connaissance approfondie des domaines business et techniques liés au projet est cruciale. L’approche agile repose sur des experts métier travaillant en étroite collaboration avec les experts de l’équipe technique. Ce qui rend les méthodologies agiles Agile, c’est la réactivité à l’évolution des besoins. Les techniciens et les personnes du business compétents doivent constamment réévaluer les livrables du projet, les besoins de l’entreprise aux niveaux macro et micro et la priorité des fonctionnalités requises par le client final.

Le Sponsor a-t-il un état d’esprit Agile ?

Le sponsor doit être disposé à participer à des revues fréquentes du produit en construction, qui sont fondamentales dans l’approche agile. La réactivité agile aux conditions changeantes de l’entreprise et son environnement évolutif sont très différentes des méthodes de projet traditionnelles. Si un sponsor veut un ensemble linéaire et méthodique d’objectifs livrés selon un calendrier prédéfini, il aura du mal avec les livrables du projet en approche agile. Les sponsors qui sont mal à l’aise avec la nature évolutive de l’agilité créent des difficultés qui peuvent couler le projet.

L’équipe peut-elle être co-localisée (physiquement ou virtuellement) ?

Agile implique un dialogue profond, interactif et parfois difficile. Pour tirer le meilleur parti de ce dialogue, vous devez créer l’environnement le plus riche possible. Co-localisez les membres de votre équipe de projet si possible. Si vous ne pouvez pas, simulez la colocalisation avec les meilleurs outils vidéo et audio que vous pouvez obtenir. Essayez de faciliter un dialogue agile avec des outils de communication médiocres, c’est comme essayer de remorquer une caravane avec une tondeuse à gazon.

Existe-t-il une synergie entre les membres de l’équipe business et technique ?

Une équipe agile doit bien s’entendre pour réussir. Les méthodologies agiles nécessitent le dévouement d’experts business et techniques qui sont ouverts à soutenir de nouvelles idées et à se soutenir les uns les autres en tant qu’individus. Vous avez besoin d’un coach agile qui comprend et peut gérer la dynamique humaine, et qui peut favoriser un environnement où les membres de l’équipe partagent facilement leurs idées et leurs préoccupations.

Le produit peut-il être construit (et livré) de manière itérative ?

Les meilleures qualités des approches Agile proviennent de la fourniture de solutions partielles tout en apprenant de chaque itération. En plus des livrables logiciels, d’autres produits peuvent également être construits de cette façon. Avec un peu de créativité, des déménagements, la mise en œuvre de nouveaux processus et même certains projets de construction dans le bâtiment peuvent utiliser des approches agiles.

Utilisez-vous d’autres critères pour déterminer si un projet est candidat à une approche agile ?

Si oui, partagez-les avec nous !

Connaissez-vous la roue de croissance du coaching agile ?

Le 7 février 202329 décembre 2022 par mopertodans agile, best practicesLaisser un commentaire

The Agile Coaching Growth Wheel

La roue de croissance du coaching agile est un outil pour les coachs agiles, les scrum masters, les leaders et tous ceux qui souhaitent accroître leur capacité à aider et à développer les équipes et les organisations en utilisant les principes et les pratiques agiles.

La roue vous permet de réfléchir et de grandir dans votre cheminement agile.

Faites-vous aider d’un autre coach Agile pour progresser.

Tous les détails sur cette roue: https://resources.scrumalliance.org/Article/agile-coaching-growth-wheel

Nouveauté 2023 : Conférence « PIAF »: PMI France Agile 2023 le 9 mars

Le 3 février 202327 janvier 2023 par mopertodans agile, rencontres et wébinairesLaisser un commentaire

Le Thème retenu pour cette première édition est :《Ensemble, prenons un peu de recul sur l’état de l’Agilité en 2023.》

PIAF 2023, c’est quoi ?

C’est une journée de conférences Agile en distanciel avec des conférences plénières en ouverture et clôture et 3 à 6 sessions en parallèle pour permettre de partager entre 15 et 30 sessions au total.

De plus, toutes les conférences seront enregistrées et diffusées pendant l’année 2023.

Que va t-on partager ?

Que peut-on dire des méthodes, des référentiels, des outils, des pratiques Agile ?

Le manifeste Agile a déjà plus de 20 ans

Est-il encore d’actualité dans un contexte de développement à l’échelle ?
Que se passe-t-il vraiment en ce moment dans l’implantation de la démarche Agile (témoignages, retours d’expérience, …) ?
Vers quoi la démarche Agile se dirige-t-elle ?

Voici de quoi nous permettre de parler d’agilité, d’hybride, et de partager des retours d’expériences…

Détails sur le site du PMI France.

Comment votre équipe manage-t-elle ses standups ?

Le 31 janvier 202319 décembre 2022 par mopertodans agile, outils et méthodesLaisser un commentaire

Quelle que soit la façon dont votre équipe coordonne son travail, il est important que de tels événements ne soient pas perçus comme une perte de temps par l’équipe ou par les principales parties prenantes.

How does your team run their standups? par Kiron Bondale

https://kbondale.wordpress.com/2022/07/10/how-does-your-team-run-their-standups/

Que vous les appeliez Scrums, stand-ups ou daily, une façon de planifier au fur et à mesure avec une approche adaptative est d’organiser régulièrement des événements de coordination pour s’assurer que tout le monde travaille de manière alignée et sur le travail le plus important.

L’un des sujets les plus courants pour de tels événements est de discuter de l’arriéré de travail de l’équipe à court terme.

Mais de telles discussions peuvent avoir lieu de différentes manières.

Pour s’assurer que tout le monde a la possibilité de s’exprimer, une approche pourrait être de discuter du travail incomplet personne après personne.

Bien que cela ait l’avantage de s’assurer que la voix de chacun soit entendue et donne à chaque membre de l’équipe l’occasion de remonter ses préoccupations ou de confirmer les hypothèses qu’il pourrait faire, cela peut également amener les membres de l’équipe qui ont déjà parlé à se désengager de ce qui est discuté par les membres de l’équipe qui viennent après eux. Bien que cela ne soit pas très préoccupant si le travail de chaque membre de l’équipe est indépendant des autres, dans la plupart des cas, il est probable qu’il y ait des dépendances entre les membres de l’équipe au niveau d’un élément de travail ou d’une activité.

Dans de tels cas, si un membre de l’équipe « s’est déconnecté » de la conversation, il pourrait manquer quelque chose d’important pour son travail ou manquer l’opportunité de corriger une hypothèse invalide faite par les autres.

Une alternative qui résout cet inconvénient est de travailler élément de travail par élément de travail. Cela est susceptible de garder la plupart des membres de l’équipe engagés plus longtemps que l’approche personne par personne, en particulier lorsque plusieurs membres de l’équipe doivent collaborer ensemble pour terminer un élément de travail. Cependant, lorsque certains membres de l’équipe ont terminé les éléments de travail qu’ils ont choisis et soutiennent maintenant activement les autres dans l’achèvement d’éléments de travail « étrangers », tous les membres de l’équipe peuvent ne pas avoir la chance de s’exprimer.

Lorsque les éléments de travail passent par un flux de travail bien défini, une autre option consiste à discuter des éléments de travail en fonction de la phase de développement dans laquelle ils se trouvent. En supposant que les membres de l’équipe travaillent sur des éléments à travers différentes phases, cela réduira la probabilité qu’un membre de l’équipe se désengage de la conversation générale, même s’il a déjà terminé la discussion des éléments de travail dans la phase en cours.

La plupart des outils de management du travail fournissent une méthode pour organiser les éléments dans les colonnes d’un tableau de travail afin que l’équipe puisse discuter des éléments incomplets dans l’ordre dans lequel ils sont présentés. Cependant, une approche plus efficace pourrait consister à donner la priorité aux quelques éléments vitaux qui méritent vraiment d’être discutés.

Il y a 3 façons courantes de le faire

Par coût du retard

Cela comprend des considérations telles que la valeur commerciale, la réduction des risques, la dépendance d’éléments de travail à venir ou la capacité d’exploiter une opportunité.

Par durée des éléments de travail

Visualisation sous forme de tableau Kanban

En supposant que l’équipe a atteint une maturité suffisante pour n’avoir que quelques tailles d’éléments de travail différentes, l’équipe pourrait se concentrer sur la discussion des éléments de travail actifs qui sont en dehors des attentes normales en matière de durée pour leur taille.

Par statut de l’élément de travail

Cela peut être fait en commençant par les éléments de travail bloqués, puis ceux avec des obstacles identifiés, puis (si nécessaire) les autres.

Beaucoup d’équipes avec lesquelles j’ai travaillé utilisent une méthode personne par personne pour leurs événements de coordination, mais je voulais comprendre quelle était la répartition entre les différentes approches.

J’ai mené un sondage d’une semaine dans le groupe de discussion LinkedIn Project, Program and Portfolio Management de PMI et dans la communauté ProjectManagement.com.

Sur les 369 réponses reçues :

66 % ont utilisé une approche élément de travail par élément de travail,
20 % ont été traitées personne par personne,
11 % ont discuté des éléments de travail par étape de développement et
3 % ont eu une autre méthode.

Dans ce dernier cas, j’avais demandé aux répondants de fournir des détails, mais dans la plupart des cas, les commentaires reflétaient une approche par élément de travail et par ordre de priorité.

Quelle que soit la façon dont votre équipe coordonne son travail, il est important que de tels événements ne soient pas perçus comme une perte de temps par l’équipe ou par les principales parties prenantes. Discuter de l’efficacité et de l’efficience de tous les événements standard dans les sessions d’amélioration des processus, tels que les rétrospectives, est un moyen de s’assurer que cela ne se produise pas.

le livre de Kiron Bonale : « Easy in Theory, Difficult in Practice » contient 100 autres leçons sur le leadership de projet

(Si vous avez aimé cet article, pourquoi ne pas lire le livre de Kiron Easy in Theory, Difficult in Practice qui contient 100 autres leçons sur le leadership de projet ?)

Petit retour sur 7 précédents billets au sujet des Daily Scrum meetings

5 manières pour le #ScrumMaster d’améliorer ses réunions quotidiennes « Daily Standups »
Le Manager dans les Daily Scrum : Quelles sont les choses à ne pas faire en dehors d’éviter totalement sa présence.
Comment surmonter 4 objections communes au « Daily Scrum » ?
a 30′ video introduction to Scrum: Did you know that 11 Million people participate in Daily Scrum Meetings ?
3 questions pour grandement améliorer l’efficacité de vos réunions quotidiennes ou « daily stand-up meeting »
Comment réussir vos « Daily Scrums » avec des équipes géographiquement distribuées ?
5 pièges à éviter dans les réunions debout, les désormais célèbres Daily Stand-Up meetings de Scrum

Dans les délais prévus

Le 27 janvier 202327 janvier 2023 par mopertodans agile, best practicesLaisser un commentaire

Quels sont les bénéfices à avoir des délais bien définis ?

On schedule par Seth Godin

https://seths.blog/2022/01/on-schedule/

Nous tirons un énorme avantage de prendre un engagement simple :

Nous respectons les délais.

L’avantage est qu’une fois que nous avons convenu de la date limite, nous n’avons plus à nous en soucier. Nous n’avons pas à négocier, à trouver des excuses ni même à stresser à ce sujet.

Il ne sera pas livré quand il sera parfait.

Il sera livré quand nous avons dit qu’il le serait.

Une fois que ceci est clair, la qualité de ce que nous expédions augmente grandement. Au lieu de passer du temps et de l’énergie à chercher des raisons, des excuses ou à être dans le déni, nous faisons simplement le travail.

Et au fil du temps, nous estimons de mieux en mieux les délais sur lesquels nous engager. Parce que si nous promettons, nous livrons.

Selon moi, comme avec l’approche Agile, les délais et les moyens sont fixés au départ, la variable d’ajustement devient le contenu et surtout la priorisation de ce contenu en fonction de sa valeur business et de la capacité de l’équipe à livrer.

Il y a des différences très significatives entre « Mechanical Scrum » et « Professional Scrum », les connaissez-vous ?

Le 14 décembre 202215 décembre 2022 par mopertodans agile, outils et méthodesLaisser un commentaire

« Mechanical Scrum » consiste à appliquer les principes et cérémonies de Scrum. « Professional Scrum » va plus loin, changeant la manière dont vous travaillez, pensez et agissez.

Cette brève vidéo de Scrum.org revient sur les idées qui supportent « Professional Scrum » et expose comment cela dépasse le Scrum Guide.

Et cette vidéo, plus longue et en français, entre dans les détails de ce qu’est Scrum Professionnel

French edition Scrum Pulse – Ne faites pas semblant, pratiquez Scrum professionnel ! avec Fabio Panzavolta

Scrum a été développé à l’origine pour des projets complexes de développement de logiciels. Il est maintenant utilisé pour presque tout type de produits crées en équipe. Le cadre, tel qu’il est défini dans le Guide Scrum, est un moyen simple mais puissant de mettre de l’ordre dans la complexité par l’apprentissage en fournissant des occasions fréquentes de feedback à la fois sur la façon de travailler et sur ce sur quoi nous avons et aurons à travailler.

Bien que de nombreuses personnes pratiquent Scrum, le pratiquer efficacement exige quelque chose de plus que de simplement suivre les mécanismes et les principes fondamentaux du cadre. Scrum professionnel aide les équipes à se défaire de cette habitude mécanique et routinière lorsqu’il s’agit de Scrum.

Dans ce webinaire Scrum Pulse, Fabio Panzavolta, PST @Scrum.org, partage avec les participants en quoi le Scrum professionnel est différent et comment il requiert les valeurs de Scrum, une mentalité et des méthodes de travail et de pensée différentes, en se concentrant sur les résultats et un environnement qui soutient le Scrum professionnel, y compris la confiance.

Lien original au webcast, avec présentation à télécharger : https://www.scrum.org/resources/french-edition-scrum-pulse-ne-faites-pas-semblant-pratiquez-scrum-professionnel

Comment découpez-vous votre travail ?

Le 5 décembre 20225 décembre 2022 par mopertodans agile, best practices, outils et méthodesLaisser un commentaire

Il existe une variété infinie de projets, cependant seulement 3 approches sont utilisées par la plupart des équipes qui développent des WBS.

How do you breakdown your work? par Kiron Bondale

https://kbondale.wordpress.com/2022/05/15/how-do-you-breakdown-your-work/

La septième édition du Guide PMBOK® définit une structure de répartition du travail (WBS) comme une « décomposition hiérarchique de la portée totale du travail à effectuer par l’équipe projet pour atteindre les objectifs du projet et créer les livrables requis ».

Bien que cette définition permette de bien comprendre ce qu’est une WBS, elle ne fournit pas de conseils sur la façon d’organiser la structure d’une WBS. Ceci est utile car cela donne aux équipes la flexibilité nécessaire pour déterminer quel est le moyen le plus approprié de le faire dans le contexte de leur projet.

Bien qu’il existe une variété infinie de projets, j’ai trouvé 3 approches utilisées par la plupart des équipes qui développent des WBS.

Axée sur les livrables – Chacun des composants de niveau supérieur de la WBS représente un livrable clé, et les niveaux suivants se concentrent sur la décomposition de ces livrables à un niveau de détail approprié.
Axée sur les phases – Chacune des composantes de niveau supérieur de la WBS représente une phase ou une étape du cycle de vie du projet, et les niveaux suivants se concentrent sur la décomposition des extrants de chacune de ces phases ou étapes.
Axée sur la responsabilité – Chacune des composantes de haut niveau de la WBS représente une partie prenante contribuant à l’exécution du projet, et les niveaux suivants se concentrent sur la décomposition des extrants produits par chacune de ces parties prenantes.

Une approche axée sur les livrables

Aide à concentrer l’équipe sur tout ce qui est nécessaire pour réaliser chaque livrable sans se soucier à ce stade de qui le fait ou quand cela serait fait. Cela peut bien fonctionner pour les projets où toute la portée d’un projet peut être décomposée dès le début, mais peut être difficile lorsqu’une approche par vagues (rolling waves) est adoptée, à moins qu’il n’y ait une identification claire des parties de planification qui doivent être élaborées à une date ultérieure.

Une approche axée sur les phases

Fonctionne bien avec une approche par vagues, car l’équipe n’a qu’à se concentrer sur ce qui sera achevé dans la phase à venir.

Cependant, il existe un risque que l’équipe manque des éléments clés de la portée pour des livrables spécifiques, car elle ne se concentrera pas sur la décomposition d’un seul livrable à la fois.

Une approche axée sur la responsabilité

Fonctionne bien lorsqu’il y a plusieurs parties prenantes et qu’il est nécessaire d’avoir une séparation claire des responsabilités en matière de planification et d’exécution. Elle présente le même risque que l’approche axée sur les phases, mais en plus grave, car il est possible que des livrables sous-composants soient assumés par chaque partie prenante comme étant la responsabilité d’une autre partie prenante.

Sondage auprès des professionnelles et professionnels du management de projet

J’ai mené un sondage dans le groupe PMI’s LinkedIn Project, Program and Portfolio discussion group ainsi que dans la communauté ProjectManagement.com pour évaluer la répartition dans l’utilisation de ces 3 approches.

Sur les 141 réponses combinées :

57 % utilisaient une ventilation axée sur les livrables
28 % une approche axée sur les phases
9 % une approche axée sur la responsabilité
Les 6 % restants ont indiqué qu’ils utilisaient une autre approche, mais lorsque j’ai examiné les commentaires que ces participants avaient soumis, il semble qu’ils utilisent simplement une combinaison de ces méthodes plutôt que quelque chose d’entièrement nouveau.

Bien que le WBS soit un outil couramment utilisé avec des projets suivant un cycle de vie prédictif, cela ne signifie pas que ceux qui suivent un cycle adaptatif ne peuvent pas en bénéficier. Si nous considérons une user story map*, il s’agit simplement d’une WBS limitée entre deux et quatre niveaux et élaborée de manière progressive. Avec une Story Map, la structure peut être orientée persona (rôle des utilisateurs) ou thème/capacité.

Quelle que soit la façon dont votre équipe choisit de décomposer la portée du travail sur ses projets, une WBS ou une variante de celle-ci doit être considérée comme un instrument précieux dans sa boîte à outils.

Partenaire de DantotsuPM, CERTyou est le spécialiste des formations certifiantes

* Une user story map est un outil puissant qui permet à une équipe agile de préparer son backlog de produit et de planifier plus efficacement les versions de produits. Une user story map capture le parcours d’un client avec le produit, y compris les activités et les tâches qu’il effectue avec le système.

Comment ré-estimez-vous les histoires utilisateurs inachevées lors d’un sprint avec l’approche Scrum ?

Le 24 novembre 202224 novembre 2022 par mopertodans agileLaisser un commentaire

Lorsque le travail n’est pas terminé dans le sprint, que faites-vous ?

When Work Isn’t Finished In the Sprint, What Do You Do? par Joel Bancroft-Connors

https://resources.scrumalliance.org/Article/re-estimate-unfinished-stories?utm_campaign=practical-agility&utm_medium=dantotsuPM

Est-ce que vous ou votre équipe avez déjà dit :

« Nous n’avons pas terminé tout le travail de ce sprint. Nous allons découper l’histoire afin d’obtenir du crédit pour le travail que nous avons déjà réalisé. »

« C’est fait à 90%, il faut juste le tester. Passons de 13 points à 1 point pour le prochain sprint. »

« Wow, c’est bien plus que 5 points. Nous aurions dû en faire un item à 13 points. »

« Nous n’avons pas terminé ces quatre histoires, nous allons simplement les reporter au prochain sprint. »

« C’est fait, il faut juste le tester. Créons une nouvelle histoire juste pour ça et marquons celle-ci comme terminée. »

J’entends ces phrases et d’autres similaires tout le temps. L’estimation, dans des circonstances normales, est difficile. Ensuite, tenez compte de ce qu’il faut faire lorsque vos estimations étaient « fausses » et que cela devient carrément désordonné. Ces exemples sont les raisons et les scénarios les plus courants que j’entends lorsque les gens posent des questions sur la réestimation du travail.

Alors, comment ré-estimez-vous le travail inachevé ?

Réponse courte : Je ne le fais pas.

Je ne ré-estime jamais le travail qui n’est pas terminé. Il n’a pas répondu à la définition de Done et retourne dans le l’arriéré de produit (le « backlog produit ») où il pourra être pris en compte pour le prochain sprint.

L’estimation ne change pas parce que nous avons commencé ou que c’est plus difficile que nous le pensions, et nous n’obtenons aucun crédit pour un travail qui n’est pas « terminé ».

En tant que « sauveteur » chef de projet, j’aime beaucoup la simplicité de la définition de Fait (Done) (les mesures de qualité requises pour le produit). Comme le binaire n’est qu’une série de 1 et de 0, la définition de Done n’a que 2 états, « Done » et « Not Done ».

À la fin du sprint , nous examinons chaque élément du backlog produit et nous nous demandons : « Est-ce que cela répond à la définition de Done ? » Si la réponse est oui, elle va à la revue du sprint. Si la réponse est non, cela retourne dans l’arriéré de produits.

« Not Done » est également très précis : l’élément de l’arriéré de produit n’est pas utilisable et ne génère donc aucune valeur. Cela retourne dans l’arriéré de produits et je le traite comme si aucun travail n’avait été fait. C’est dans l’arriéré de produit et vous le traitez comme n’importe quel autre élément du backlog. Il a juste l’avantage de plus de « préparation ».

Pourquoi ne ré-estimez-vous pas ?

C’est une bonne question. Il y a un certain nombre de raisons de traiter un item « Not Done » comme n’importe quel autre élément de l’arriéré de produit.

Doit être utilisable

La première raison vient directement du Guide Scrum. « Afin de fournir de la valeur, l’incrément doit être utilisable. » Je ne divise pas une histoire juste pour obtenir un crédit partiel. Si j’avais pu le diviser en un travail plus petit et qu’il était encore utilisable, j’aurais déjà dû le faire en guise de préparation. Nous nous concentrons sur les résultats (la valeur) et non sur les livrables (le travail accompli).

Le code pourrit

J’ai appris cela d’un développeur expérimenté il y a des années. Même dans les environnements où la « production » ne change que tous les six mois, la base de code peut changer beaucoup en une semaine. Lorsque le travail a commencé sur la nouvelle interface de connexion, les environnements étaient à l’état X. À la fin du sprint, les environnements étaient à l’état Y et lorsque nous avons finalement terminé l’interface de connexion, deux sprints plus tard, les environnements étaient à l’état Z. J’ai vu du travail qui répondait à la définition de Done dans le sprint précédent planter le système construit parce qu’il n’a été déployé que quatre semaines plus tard. « Il faut juste le tester », est probablement tout en haut avec « qu’est-ce qui pourrait mal tourner? » dans les déclarations qui précèdent la catastrophe.

Ne prenez pas de raccourci

Ceci est étroitement lié à la pourriture du code. Si le travail n’est pas terminé dans le sprint, je ne le reprends pas dans le sprint suivant comme si rien n’avait changé. Je prends toutes les tâches (qui ne sont pas Done) et les ramène à « à faire » (To Do). Lorsque je reprends le travail, je valide à nouveau tout le travail. Non seulement le « code pourrit », mais vous avez peut-être appris quelque chose de nouveau, avez une nouvelle approche, quelqu’un d’autre a fait le travail. En revenant au tout début, vous vous assurez que rien n’a été manqué et que la qualité reste élevée.

Le tout s’équilibre

Cela entre en jeu à la fois avec un travail qui est « presque terminé » et un travail qui est « ouh la la ! C’est beaucoup plus gros que ce que nous pensions ». Vous allez reprendre un travail qui a été entrepris dans un sprint précédent et qui était à 1 point d’effort de finir, et vous allez également prendre un travail qui finira par nécessiter trois fois plus de travail que prévu, et à long terme, le tout s’équilibre. La loi des grands nombres nous dit essentiellement que, au fil du temps, le nombre d’éléments surestimés s’équilibrera avec le nombre de sous-estimés.

Ne le faites pas

Si cela n’a pas été fini dans le sprint, profitez-en pour examiner le travail à nouveau. Commencez par les critères d’acceptation. Sont-ils trop vagues ? Peut-on y répondre par oui ou non ? Regardez au-delà de cet élément de l’arriéré pour avoir une vue d’ensemble. L’équipe prend-elle trop de travail, cet élément dépendait-il d’un autre élément, y a-t-il une difficulté avec la définition de Done ?

Enfin, profitez-en pour poser la question suivante

Devrions-nous encore faire ce travail ?

Chaque sprint est une opportunité d’inspection et d’adaptation. Une partie consiste à examiner tout ce qui se trouve dans l’arriéré de produit et à vous demander si cela soutient toujours l’objectif du produit.

Quelles sont les caractéristiques clés des Product Owners qui sont des CRACKs ?

Le 22 novembre 20224 novembre 2022 par mopertodans agile, pmo et portofolioLaisser un commentaire

En 2003, Barry Boehm et Richard Turner ont inventé l’acronyme C.R.A.C.K. pour nous rappeler les caractéristiques clés d’un Product Owner efficace !

Collaboratif – Est-il capable et disposé à négocier avec les parties prenantes sur les besoins, les souhaits et les priorités afin de définir un contenu de produit optimal ?
Livre référence sur Amazon

Représentatif – Est-il capable de « se mettre dans les chaussures » d’une partie prenante donnée pour aider les membres de l’équipe et d’autres personnes à comprendre le contexte derrière un besoin particulier ?
Autorisé – Est-il habilité à prendre la majorité des décisions de priorisation sur le produit sans avoir besoin de demander l’approbation de ses supérieurs ?
Comitted (engagé) – A-t-il pleinement adhéré à la vision du produit et a-t-il une capacité suffisante pour s’acquitter de ses responsabilités en tant que Product Owner ?
Knowledgeable (Connaissance) – Possède-t-il une connaissance suffisante du domaine du produit, mais aussi a-t-il le savoir-faire organisationnel pour savoir qui engager, influencer ou persuader ?

Merci à Kiron Bondale pour le pointeur sur « Balancing Agility and Discipline: a guide for the perplexed », publié par Addison-Wesley en 2004

Cet acronyme me semble s’appliquer également fort bien aux responsables de Project Management Office (PMO), les bureaux de projets, ainsi qu’aux portefeuilles de projets (PPM) !

Visitez le site de notre partenaire Virage Group

La controverse sur les Story Points : Quelle est leur réelle valeur ?

Le 15 novembre 202215 novembre 2022 par mopertodans agileLaisser un commentaire

Voici un billet que j’ai trouvé très intéressant sur la réelle valeur des story points et les raisons pour lesquelles ils créent des conflits dans vos projets Agiles.

The Story Point Controversy par Natalie Barnes

https://resources.scrumalliance.org/Article/story-point-controversy

L’estimation du travail agile fait l’objet de débats dans les organisations depuis des années. Il existe plusieurs techniques d’estimation, mais les story points, en particulier, peuvent être un mystère pour beaucoup. Bien qu’il s’agisse d’une méthode couramment utilisée, certains peuvent questionner son efficacité. Cet article décrit le but des story points et pourquoi ils peuvent être sujets à controverse.

Qu’est-ce qu’un Story Point ?

Un story point est une unité de mesure d’une user story basée sur des facteurs tels que la complexité, l’effort, l’incertitude et le risque. Les story points peuvent être utilisés dans des approches agiles comme Scrum lors de la planification du sprint en attribuant une valeur en points à une user story.

Le story-pointing est un moyen rapide d’estimer le travail à l’aide d’outils tels que Planning Poker ou le modèle de Fibonacci. Par exemple, l’équipe peut attribuer un 1 ou un 2 à une histoire qu’elle considère comme nécessitant peu d’effort. L’objectif est d’aider les équipes Scrum à avoir un dialogue ouvert pour acquérir une compréhension commune du travail relatif à toutes les histoires utilisateurs dans l’arriéré de produit, le product backlog.

Relisez ce billet sur « pourquoi Fibonacci ? »

Toute l’équipe (ceux qui font le travail) discute des éléments et des composants impliqués dans le développement de l’histoire utilisateur et parvient à un consensus sur l’estimation en story points. Certaines équipes établissent une base de référence convenue pour l’histoire d’effort le plus faible avec le nombre de story points le plus bas. Si une user story a un nombre très élevé de points, l’équipe décompose l’histoire en histoires plus petites puis les estime.

Comment les story points sont-ils utilisés dans les sprints ?

Une fois que la planification du sprint est terminée et que l’équipe a décidé de ce à quoi elle peut s’engager dans le sprint, elle a alors son nombre total de points d’histoire, de story points, engagés. À la fin du sprint, l’équipe aura consommé tous les story points qui répondent à leur définition de terminé, done. Toutes les histoires qui ne sont pas complètes sont alors soit déplacées dans le backlog, peut-être affinées et ré-estimées, soit reportées au sprint suivant : c’est une décision d’équipe.

L’équipe répète ce processus pour chaque sprint. Au fil du temps, les membres développent leur vélocité, qui est une moyenne du nombre total de story points complétés à la fin de chaque sprint. Les story points terminés peuvent varier à chaque sprint en fonction de la capacité de l’équipe (temps disponible pour chaque sprint). Les facteurs qui pourraient avoir une incidence sur la capacité comprennent le nombre de membres de l’équipe travaillant dans le sprint en raison d’un congé personnel ou d’une maladie, d’une formation ou de conférences, d’événements imprévus, de distractions externes ou peut-être d’un sprint lourd en réunions (pensez aux réunions de département ou d’organisation).

Pourquoi les story points peuvent-ils être sujets à controverse ?

Étant donné que les story points sont une valeur nébuleuse et arbitraire, certaines organisations peuvent ne pas comprendre l’unité réelle de cette mesure des histoires utilisateur. Elles peuvent mal interpréter leur objectif, et il est difficile d’associer systématiquement les points d’histoire au délai de livraison. Prenons la vélocité, par exemple. Elle est considérée comme une mesure clé dans Agile, mais elle peut être utilisée à mauvais escient lors de la mesure de la productivité d’une équipe. Les dirigeants peuvent poser des questions sur la vélocité de l’équipe et vouloir savoir combien de points d’histoire ils achèvent à chaque sprint. Cet état d’esprit de la vélocité en tant que mesure de productivité utilisant des story points ne donne pas une bonne idée de la productivité ni du temps qu’il faudra à l’équipe pour livrer une fonctionnalité.

Disons que l’équipe prend en charge et complète 20 story points dans le sprint 1. Dans le sprint 2, ils prévoient 40 story points mais ne complètent que 30 story points. Dans le sprint 3, ils embarquent et complètent 30 points d’histoire. Cela ne signifie pas que l’équipe est plus ou moins productive de sprint en sprint. Cela fait partie du processus de planification de l’équipe pour déterminer ce qu’elle peut engager dans chaque sprint compte tenu de son expérience du dernier sprint. Étant donné que les user stories présentent différents degrés de complexité et d’incertitude, l’équipe a peut-être appris que ses estimations lors de la planification du sprint étaient trop élevées ou trop basses et s’ajuste en conséquence à chaque sprint.

La capacité de l’équipe est une autre raison pour laquelle les story points peuvent fluctuer. Peut-être qu’ils n’ont pas pu en terminer autant qu’ils l’avaient prévu en raison d’une personne malade dans l’équipe ou d’un autre événement inattendu.

Les story points sont également utilisés à mauvais escient comme métrique pour comparer une équipe à une autre. L’équipe A peut avoir une moyenne de 40 story points tandis que l’équipe B peut avoir une moyenne de 80 story points. Le management peut mal interpréter cela comme signifiant que l’équipe A est deux fois plus productive que l’équipe B. Il n’y a pas deux équipes égales. Leurs membres peuvent avoir des compétences différentes, la taille des équipes peut être différente et les définitions d’un story point peuvent varier. La comparaison des équipes nuit à leur processus d’estimation, crée des estimations gonflées et démoralise l’équipe.

Trouvez un équilibre

Il est compréhensible que les organisations aient besoin de savoir à quel point les équipes sont productives et elles ont besoin de quelque chose de tangible pour mesurer leur performance. Cependant, il est erroné de supposer que les story points et la vélocité sont des mesures d’évaluation de la productivité. Les story points sont utilisés par l’équipe Scrum à des fins de planification et ne doivent pas être considérés comme une unité de productivité par la direction. La vélocité en tant que métrique doit être utilisée par l’équipe Scrum comme point de référence pour les aider dans leur prise de décision pour les engagements de sprint.

Les apprentissages continus et l’expérience de l’équipe donnent la possibilité à l’équipe Agile d’améliorer ses estimations au fil du temps.

Grâce à l’inspection et à l’adaptation, les membres de l’équipe deviennent plus prédictifs et capables de prévoir les délais pour les fonctionnalités. Ce qui compte dans l’agilité, c’est un dialogue ouvert et productif sur le travail, la progression vers l’objectif du produit et la création fréquente de valeur pour les clients.

Qu’est-ce qui challenge le plus vos équipes avec Scrum ?

Le 4 novembre 20223 novembre 2022 par mopertodans agile, experience sharingLaisser un commentaire

L’un des clichés à propos de Scrum est qu’il est « facile à comprendre mais difficile à maîtriser ».

What challenges teams most with Scrum? de Kiron Bondale

https://kbondale.wordpress.com/2022/03/20/what-challenges-teams-most-with-scrum/

L’un des clichés à propos de Scrum est qu’il est « facile à comprendre mais difficile à maîtriser ».

La première partie de ce cliché est évidente car le Guide Scrum ne comporte que 11 pages (si vous ne comptez pas la page de titre, l’objectif et la table des matières). Il y a 3 rôles, 3 livrables et 4 événements/cérémonies (cinq si vous incluez les sprints en tant qu’événement, mais je préfère ne pas le faire car l’idée générale d’événements dans des événements me donne la nausée).

La deuxième partie de ce cliché devient apparente une fois que vous essayez d’implémenter Scrum dans un système existant. Ce n’est que dans de très rares cas qu’il est possible d’introduire Scrum sans affecter radicalement la façon de travailler de l’équipe. Ceci, en soi, n’est pas une mauvaise chose car l’amélioration des résultats de livraison implique un certain nombre de changements.

Cependant, la nature immuable de Scrum est l’endroit où les défis se matérialisent. En surface, introduire un nouvel ensemble d’événements ou de livrables ne semble pas trop drastique, mais lorsqu’il s’agit de remplacer les rôles, les livrables et les événements existants par les rôles Scrum, et de les mettre en œuvre tels qu’ils sont destinés à être utilisés, c’est là que les défis émergent.

Compte tenu de mes observations personnelles sur les problèmes d’adoption de Scrum, j’ai pensé qu’il serait utile de sonder un public plus large sur l’aspect de Scrum qui a généré le plus de défis.

Au total, 35 membres de la communauté LinkedIn PMI Project, Program and Portfolio Management ont répondu au sondage avec la répartition suivante des votes :

Les événements/cérémonies : 31 %
Les rôles : 31 %
Les livrables/artefacts : 17 %
Le timeboxing de 1 à 4 semaines : 20%

Cela concorde avec ce que j’ai observé.

Bien qu’il puisse y avoir des problèmes de qualité avec les sprints et les arriérés de produits, et que les équipes immatures ne produisent pas toujours un incrément, il ne faut généralement pas trop de temps à la plupart des équipes pour se familiariser avec ces artefacts. De même, bien qu’il puisse être nécessaire d’augmenter la durée du sprint lorsque vous prenez en compte des contraintes du « monde réel » des projets non logiciels, au fil du temps, les équipes s’améliorent pour découper les éléments de travail de sorte que « quelque chose » de valeur puisse être produit en peu de temps.

Les plus grands défis que j’ai vus concernent l’adoption correcte des événements et des rôles Scrum.

Qu’il s’agisse des Daily Scrums qui se transforment en réunions de statut, de rétrospectives de sprint dangereuses psychologiquement, de revues de sprint auxquelles n’assiste aucune partie prenante externe ou de planification de sprint qui prend des jours à compléter, le but et les conditions préalables à la réussite des événements se perdent dans leur mise en œuvre.

La propriétaire de produit comprend le métier et les taches des utilisateurs du futur produit.

Alors que nous voulons tous des Product Owners fantastiques et des équipes « entières » interfonctionnelles, nous nous retrouvons avec des Product Owners qui n’ont aucun pouvoir décisionnel ou pas de temps, et une répartition imprévisible des membres de l’équipe d’un sprint à l’autre.

Aussi, lorsque nous considérons le grand nombre de conditions requises pour permettre à Scrum d’être mis en œuvre tel que conçu, la probabilité qu’elles soient toutes remplies au sein d’une organisation typique est assez faible.

Et c’est pourquoi « Scrumbut » (Scrum mais…) est la valeur par défaut, pas l’exception.

+++++++++++++++++++++++++++

Qu’est-ce que le « Scrumbut » ?

https://www.scrum.org/resources/what-scrumbut

Les ScrumButs sont des raisons pour lesquelles les équipes ne peuvent pas tirer pleinement parti de Scrum pour résoudre leurs problèmes ni tirer pleinement parti du développement de produits à l’aide de Scrum.

Chaque rôle, règle et timebox Scrum est conçu pour fournir les bénéfices souhaités et résoudre les problèmes récurrents prévisibles.

Scrumbut – L’équipe contourne le problème plutôt que le résoudre.

ScrumBut signifie que Scrum a mis en évidence un dysfonctionnement qui contribue au problème, mais qui est trop difficile à résoudre.

Un ScrumBut conserve le problème tout en modifiant Scrum pour le rendre invisible afin que le dysfonctionnement ne soit plus une épine dans le pied de l’équipe.

Un ScrumBut a une syntaxe particulière : (ScrumBut)(Raison)(Contournement)

Exemples de ScrumBut

« (Nous utilisons Scrum, mais) (avoir un Daily Scrum tous les jours génère trop de frais) (donc nous n’en avons qu’un par semaine.) »
« (Nous utilisons Scrum, mais) (Les rétrospectives sont une perte de temps) (donc nous ne les faisons pas.) »
« (Nous utilisons Scrum, mais) (nous ne pouvons pas créer une fonctionnalité en un mois) (donc nos Sprints durent 6 semaines.) »
« (Nous utilisons Scrum, mais) (parfois nos managers nous confient des tâches spéciales) (donc nous n’avons pas toujours le temps de répondre à notre définition de Done.) »

Un produit minimum viable n’est pas toujours la chose la plus précieuse pour une startup

Le 24 octobre 202226 septembre 2022 par mopertodans agile, best practices, experience sharingLaisser un commentaire

Certaines startup décident de ne pas construire de MVP et d’attendre que le produit soit complet et mature avant de demander à des clients potentiels de l’essayer et fournir des retours. Vous voudrez peut-être aussi envisager cette approche…

A minimum viable product is not always a startup’s most valuable player de Srikrishnan Ganesan

https://www.mindtheproduct.com/a-minimum-viable-product-is-not-always-a-startups-most-valuable-player/

Une pratique courante de lancement de startup consiste à créer d’abord un produit minimum viable (MVP). Largement considéré comme la meilleure première étape pour prouver un produit, un MVP permet à une startup de commercialiser rapidement une version initiale du produit et de solliciter au plus tôt les commentaires des clients pour l’améliorer avant de lancer le produit. Avec un MVP, une startup peut se concentrer sur la unique selling proposition du produit, la proposition de valeur qui rend le produit unique, et construire autour de celle-ci.

Rocketlane a pris un chemin différent. Nous n’avons pas construit de MVP, mais nous avons attendu que le produit soit complet et mature avant de nous engager avec des clients potentiels et de leur demander de l’essayer et de fournir des retours. Vous voudrez peut-être aussi envisager cette approche lorsque vous évaluerez diverses façons de mettre votre produit sur le marché. Dans cet article, nous allons vous expliquer pourquoi.

Pourquoi casser les codes ?

Un MVP fonctionne bien lors de la création d’un produit entièrement nouveau pour un nouvel espace et pour des solutions ponctuelles simples pour les petits clients. Cependant, si un produit doit remplacer des produits horizontaux matures par des solutions spécialement conçues, le produit ne réussira pas en commençant en tant que MVP, d’autant plus si le produit cherche à unifier, en remplaçant un ensemble d’outils horizontaux cloisonnés.

La signification du MVP – Corriger les idées fausses les plus courantes

Les principaux piliers de notre histoire de produit sont ses capacités de « tout-en-un » et « d’unification », rassemblant les tâches, les rapports de projet, les notes de réunion, la collaboration de documents en direct et les flux de travail dans une expérience étroitement couplée.

Nous devions intégrer tous ces composants dans notre toute première version de produit et livrer un produit avec une gamme significative de fonctionnalités dès le premier jour. Pour gagner l’adhésion, un produit qui promet une expérience tout-en-un doit faire au moins 80% de ce que fait chacune des solutions horizontales. Le produit doit d’abord avoir toutes ses fonctionnalités de base en place, puis ajouter une couche d’innovation au-dessus.

Distractions et détours

Si vous créez un produit tout-en-un remplaçant plusieurs outils établis et cloisonnés, ce n’est pas non plus une bonne idée de développer et de lancer chaque module séquentiellement en tant que MVP. Si vous donnez un module ou une partie de votre solution à vos clients potentiels pour qu’ils la testent, ils vous fourniront des retours pour améliorer cette partie, ce qui pourrait vous faire perdre de vue votre solution complète.

Supposons que vous alliez plus loin et que vous lanciez une partie de votre produit en tant que MVP, alors l’ensemble du marché pourrait fournir des commentaires similaires et vous faire perdre encore plus de concentration sur votre vision plus aboutie. Vous lanceriez également un MVP qui n’est probablement pas encore au niveau en le comparant fonctionnalité par fonctionnalité avec l’une des solutions établies et cloisonnées que vous souhaitez remplacer, ce qui pourrait entraîner des critiques plus mitigées que vous ne le recevriez autrement si vous aviez attendu pour livrer votre vision complète.

Ne laissez pas un client vous entraîner dans la spirale d’une vision qui lui est propre.

Un autre risque à lancer ou engager des clients potentiels avec un module MVP de votre produit est de suivre LEUR vision de ce module.

Il pourrait finir par ressembler à d’autres produits déjà sur le marché, car ils vont comparer chaque module MVP à d’autres solutions cloisonnées qu’ils utilisent ou connaissent déjà.

Il est préférable d’allouer du temps et des ressources à l’analyse des retours des clients sur des modules et des fonctionnalités spécifiques après avoir livré la vision complète et votre différenciation.

Construire dans les délais lors de la création d’un produit

Une autre raison d’impliquer les clients potentiels tard dans la phase de développement est que les clients jugent en fonction de l’agilité et de la vitesse de production. Lors de la construction des fondations d’un produit, les clients ne percevraient peut-être pas de progrès mensuels significatifs. Plutôt que d’impliquer les clients potentiels dans les premières étapes et risquer la désillusion, il est préférable d’attendre les derniers mois avant le lancement.

Une fois que vous avez un bon produit qui est à 80% de ses fonctionnalités, il ne devrait pas être difficile d’engager des clients potentiels à l’essayer pour quelques équipes et cas d’usage, puis à itérer rapidement avec eux pour atteindre l’adéquation produit / marché cible.

La présentation d’un nouveau produit presque fini aux clients potentiels garantit également qu’ils n’ont pas besoin d’imaginer ce qu’il sera à l’avenir. Ils le voient déjà fonctionner avec succès en fonction de votre vision et peuvent mieux comprendre cette valeur.

Idéalement, les clients potentiels verraient également qu’il n’y a pas d’autre produit équivalent sur le marché ni ailleurs. Lorsqu’ils utilisent le produit en fonction de votre vision complète, ils doivent également imaginer comment cela pourrait les aider.

MVP or EVP (Exceptional Valuable Product) : Which is the Best Option for Your Startup?

Gestion des risques

Impliquer des clients potentiels tard dans la phase de développement inclut le risque de construire trop sans le valider. Le risque augmente avec l’ampleur et la complexité du produit. Même si vous avez de l’expérience dans la création de produits et que vous connaissez la direction, les demandes des clients et ce dont ils peuvent et ne peuvent pas se passer, il est préférable d’engager un panel d’examinateurs, pas nécessairement des clients potentiels, qui sont intéressés par votre vision. Dès la phase de conception, vous pouvez leur montrer des maquettes de ce que sera votre produit complet. De cette façon, vous aurez un flux de retours sur les démonstrations de maquettes même pendant la construction du produit, ce qui vous aidera à réduire les risques.

Vendre la vision

Vous devrez peut-être éduquer les investisseurs et les employés sur votre approche de produit mature. Les deux groupes peuvent être plus familiers de l’approche MVP et peuvent se demander pourquoi attendre la fin de la phase de développement pour engager des clients potentiels. Vous pouvez manager cela avec des réunions régulières où vous présentez les progrès et répondez aux questions. Vous pouvez également distribuer une note de service écrite aux investisseurs et employés, ce qui serait un bon exercice pour cristalliser votre pensée et pour les deux groupes d’avoir un document de référence.

Un produit mature est le produit le plus viable

Il y a plus d’une façon de construire un produit, en particulier pour les catégories horizontales et compétitives. Au lieu de créer un MVP, vous voudrez peut-être créer un produit avec plus de maturité et d’étendue avec quelques expériences innovantes clés qui servent de promesse différenciante (unique selling proposition) et illustrent pourquoi votre produit est le meilleur pour des cas d’utilisation spécifiques.

Si vous engagez les clients potentiels lorsque le produit semble mature, ils comprendront pourquoi ils devraient s’aligner sur votre vision et vous ne sacrifierez pas la différenciation que vous apportez sur le marché.

La signification de MVP – Corrigez les idées fausses les plus courantes !

Le 18 octobre 202221 septembre 2022 par mopertodans agile, best practicesLaisser un commentaire

Chacun a sa propre interprétation de ce que signifie un produit minimum viable (MVP) pour son organisation et, bien que les spécificités d’une définition de MVP puissent varier, ce billet explore ce qu’est un MVP et ce qu’il n’est certainement pas.

The Meaning of MVP – Correcting Common Misconceptions de Phil Tarnowski

https://www.mindtheproduct.com/the-meaning-of-mvp-correcting-common-misconceptions/

Chacun a sa propre interprétation de ce que signifie un produit minimum viable (MVP) pour son organisation et, bien que les spécificités d’une définition de MVP puissent varier, ce billet explore ce qu’est un MVP et ce qu’il n’est certainement pas.

Un MVP réussi est essentiel à la création d’un produit numérique réussi : C’est l’ensemble de fonctionnalités ciblées qui lance votre produit sur le marché, donne le ton pour l’avenir de votre produit et vous aide à vous guider vers des améliorations prioritaires sur la feuille de route du produit. C’est la version initiale qui met votre produit sur le marché et vous permet d’itérer, d’obtenir des retours et de vous concentrer sur l’adéquation produit / marché. Votre MVP n’est pas le strict minimum, ni le nombre maximum de fonctionnalités : Il se situe quelque part entre les deux.

Voici quelques choses qu’un MVP n’est certainement pas.

Squelette

Il y a 20 ans, votre nouveau produit numérique était souvent le premier à être commercialisé. Il y avait moins de solutions numériques qu’aujourd’hui et les attentes en matière d’expérience utilisateur étaient plus faibles. Aujourd’hui, les goûts et les attentes des consommateurs ont changé. Tout comme le marché (nous avons écrit un guide en anglais sur la façon de définir la première version de votre produit numérique).

Lorsqu’il existe des dizaines d’autres concurrents avec des offres de produits similaires, vous devez rendre votre MVP plus beau et plus intuitif que la concurrence. Il ne devrait pas seulement fonctionner. Il devrait résoudre de vrais problèmes et être élégant en le faisant.

Aujourd’hui, si les gens ne savent pas facilement comment utiliser un produit, ils passeront à autre chose. S’ils ne voient pas la valeur rapidement, ils passeront à autre chose. Pour cette raison, vous devez créer un MVP qui fait le travail rapidement et facilement.

Un seul et c’est fini (one and done)

Les produits numériques ne sont pas une construction où une seule version suffit. Peu importe l’expérience que vous avez des produits numériques, il y aura des fonctionnalités que vous manquerez ou sur lesquelles vous vous tromperez dans votre première version.

Vous obtiendrez des retours sur votre MVP, ce qui signifie que vous devrez revenir sur la conception pour améliorer le produit. Si vous pensez que votre premier jet sera parfait et n’aura pas besoin de changements, vous serez déçu. Tout comme une maison, les produits numériques nécessitent des améliorations et un entretien continus. Et, si votre MVP est apprécié par vos utilisateurs, vous devrez éventuellement « maintenir l’existant » et « ajouter une chambre d’amis » pour continuer à répondre à leurs attentes et vous assurer qu’ils reviennent.

Le produit parfait

Bien que votre MVP ne devrait pas être le simple squelette de toutes vos idées, il ne devrait pas non plus être toutes vos idées. Si vous passez trois ans à développer entièrement toutes les caractéristiques du produit de vos rêves, puis mettez ce produit sur le marché, vous serez probablement surpris du résultat. Vous constaterez peut-être que certaines fonctionnalités que vous pensiez être des aspects essentiels de votre produit sont déroutantes et inutiles pour vos utilisateurs.

Cela signifie que vous avez passé trois ans à construire quelque chose que vos utilisateurs ne veulent même pas. C’est une grosse perte de temps et d’argent.

Créez un MVP qui adresse les problèmes clés que vos utilisateurs doivent résoudre, mettez-le sur le marché et obtenez des retours. Répétez cette stratégie et itérez au fil du temps. La rétroaction et l’itération atténueront les risques. Cela vous aidera à créer un produit axé sur l’utilisateur. En abordant les problèmes par de petites améliorations incrémentales, vous vous assurerez de créer un produit précieux pour les personnes qui utilisent réellement le produit.

Bien que votre définition personnelle du MVP de votre produit puisse varier, assurez-vous que vous ne vous basez pas sur l’une de ces fausses idées.

Définissez votre MVP en commençant par les objectifs business à long terme et travailler à rebours.
Priorisez impitoyablement et évitez le piège d’avoir un MVP qui est un squelette ou exagérément musclé.
Et n’oubliez pas de recueillir de manière obsessionnelle des retours afin de pouvoir continuer à maintenir et à améliorer votre produit au fil du temps.

Faire – ou acheter ?

Le 14 octobre 202216 septembre 2022 par mopertodans agile, outils et méthodesLaisser un commentaire

Si déterminer quels systèmes, composants ou modules vous devriez « fabriquer » et lesquels vous devriez « acheter » reste un sujet difficile dans votre organisation informatique, quels sont les facteurs clés à considérer ?

Make – or Buy? par Michael Küsters

https://failfastmoveon.blogspot.com/2022/08/make-or-buy.html

« Agile » n’est pas une solution miracle. Le domaine est large, large et extrêmement sensible au contexte. Souvent, ce sont des nuances complexes qui font ou défont une approche. Dans ce billet, je veux partager mes expériences pour que d’autres puissent aussi apprendre.

Déterminer quels systèmes, composants ou modules nous devrions « fabriquer » et lesquels nous devrions « acheter » (par extension : utilisation à partir de l’Open Source) est un sujet difficile pour toute organisation informatique. Même lorsqu’il y a une position claire de la part de la direction du développement en faveur d’une option, ce vote est souvent formé avec une perspective myope : Les managers préfèrent « acheter » tout ce qu’ils peuvent, tandis que les développeurs hardcore préfèrent tout « faire ». Ni l’un ni l’autre n’est avisé. Mais comment décider ?

Il y a quelques facteurs clés en jeu

Facteurs	Détails
Disponibilité	Lorsqu’il existe une solution abordable et prête à l’emploi, « Achetez » pour éviter de réinventer la roue. Assurez-vous que prêt signifie prêt et « abordable » n’a aucune condition.
Unicité	Vous devez « faire » tout ce qui est unique à votre modèle business.
Adaptabilité	Lorsqu’il n’y a qu’un petit besoin de changement et de personnalisation, « Acheter » est préférable. Ne sous-estimez jamais « un petit changement ».
Durabilité	« Acheter » uniquement lorsque le coût initial et le coût du cycle de vie sont inférieurs. Inclure les coûts de migration et de décommissionnement.
Compétence	Si vous avez besoin de spécialistes que vous n’avez pas et que vous n’aurez pas, « Achetez » de quelqu’un qui les possède.
Dépendance	Si votre entreprise doit fermer ses portes quand la solution devient indisponible, « Acheter » vous met en dépendance de votre fournisseur.
Perte sèche	Vous pouvez « Acheter » pour gagner en vitesse même lorsque tous les indicateurs favorisent « Faire », si – et seulement si – vous êtes prêt à passer en perte sèche tout ce qui est investi dans la solution « Acheter ».

Choisissez judicieusement : Les réponses ne sont souvent pas si évidentes qu’elles en ont l’air.

Et vous, comment vous y prenez-vous pour répondre à la question : Faire ou acheter ?

Agile Kata : C’est quoi ? Ressources gratuites et opportunités d’aller plus loin.

Le 12 octobre 202216 septembre 2022 par mopertodans agile, outils et méthodesLaisser un commentaire

Qu’est-ce que tout ce buzz autour d’Agile Kata ? Voici de nombreuses ressources gratuites et des opportunités d’en apprendre davantage.

What is the buzz around the Agile Kata? Free Resources and Learning Opportunities par Joe Krebs

https://www.agilealliance.org/practicing-business-agility-with-the-agile-kata/

Agile Kata est-il nouveau ?

Les deux communautés, Agile et Kata, ne sont pas nouvelles. Ils ont des décennies d’expérience et de preuves de succès. Il y a des années, lorsque j’ai commencé à chercher de meilleures façons de diriger les transformations agiles, je suis tombé sur le Toyota Kata et j’ai construit un pont entre ces approches. Vous pourriez dire que le Agile Kata en lui-même est nouveau, mais les utilisateurs exploitent la richesse des expériences et des succès de deux communautés. L’intersection où Agile et Kata se rencontrent est nouvelle. Je l’ai nommé « Agile Kata » pour la rendre plus facile à référencer et à identifier.

À quoi sert l’Agile Kata ?

Agile Kata est un modèle pour aider les organisations à créer et à accroître l’agilité de l’entreprise. Comparativement, Agile Kata est appliqué au niveau organisationnel comme Scrum et Kanban le sont au niveau de l’équipe. Vous pouvez utiliser Agile Kata pour piloter une transformation agile, créer une culture agile ou conduire un changement organisationnel.

Si vous cherchez de meilleurs moyens d’augmenter l’agilité de votre entreprise avec Agile Kata

Consultez le livre blanc Agile Kata white paper sur www.agilekata.org.
Rejoignez l’un de mes brefs webinaires gratuits.
Découvrez les nombreux replays gratuits dans l’Agile Campus pour un apprentissage à votre rythme.
Procurez-vous le kit Agile Kata gratuit.
Rejoignez le groupe LinkedIn Agile Kata nouvellement créé.

Burnout des développeurs : 3 façons de l’éviter au sein de votre équipe informatique

Le 4 octobre 202213 septembre 2022 par mopertodans agile, best practicesLaisser un commentaire

L’épuisement professionnel guette les équipes de développement, en particulier avec les approches Agile. Voici trois stratégies pour le prévenir !

Developer burnout: 3 ways to avoid it on your IT team par Christine Spang

https://enterprisersproject.com/article/2022/8/avoid-developer-burnout

Le développement de logiciels est en constante évolution. En conséquence, les développeurs modernes peuvent se sentir « toujours en service », avec peu de temps d’arrêt pour se recharger. Une étude de Haystack a révélé que 83% des développeurs de logiciels souffrent d’épuisement professionnel.

Ce n’est un secret pour personne que la pandémie a augmenté les sentiments d’épuisement professionnel, mais d’autres variables exacerbent également ces ressentis. Les principales raisons citées par les développeurs dans l’étude pour l’épuisement professionnel comprenaient une charge de travail élevée (47%), des processus inefficaces (31%) et des objectifs ou des cibles peu clairs (29%).

L’expérience du développeur (DevEx) fait référence aux interactions et aux sentiments globaux qu’un développeur éprouve lorsqu’il travaille à la réalisation d’un objectif. Ceci peut jouer un rôle essentiel dans l’identification et la conservation d’expériences positives pour les développeurs et les utilisateurs finaux. Une expérience de développement sans friction qui simplifie les processus et aide à prévenir l’épuisement des développeurs est vitale.

[ Lisez aussi Burnout: 3 steps to prevent it on your team. ]

La façon dont le travail est structuré dans un environnement distant est un facteur important dans le développement d’une culture de travail positive qui permet aux entreprises de retenir et d’attirer des employés de grande valeur. L’autonomie et un certain degré d’autorité dans le temps et l’emplacement peuvent aider à restaurer un sentiment de contrôle.

3 conseils pour prévenir l’épuisement professionnel des développeurs

Voici trois solutions pour vous aider à prévenir l’épuisement professionnel au sein de votre équipe de développeurs :

#1 – Automatisez les processus simples

De nos jours, l’automatisation est un élément clé dans toute industrie, de l’IA avancée et de l’apprentissage automatique à la simple utilisation de logiciels pour effectuer des tâches plus efficacement.

Les développeurs sont devenus partie intégrante de tous les types de travail dans les organisations. Lorsque vous managez une équipe de développeurs, aidez à prévenir l’épuisement professionnel en leur suggérant les moyens les plus efficaces et les plus motivants de gérer leurs listes de tâches.

Les développeurs doivent disposer de processus rapides et structurés pour effectuer les tâches. Par exemple, l’utilisation d’outils et de technologies pour simplifier le travail complexe est une bonne pratique pour supprimer le travail répétitif et rendre la livraison du code plus rapide et plus facile. Des processus longs et laborieux embourbent les développeurs et peuvent retarder ou empêcher la satisfaction de livrer quelque chose.

Prenez le pouls de vos développeurs grâce à des enquêtes et à des réunions 1-1, et recherchez activement d’autres moyens de recueillir des informations sur ce que l’équipe pense de sa charge de travail et des processus qu’elle souhaite automatiser.

L’automatisation offre également aux développeurs plus de bande passante. En automatisant des tâches administratives simples et l’accès à de riches données de communication, et en corrigeant les processus stagnants, vous pouvez donner à vos développeurs plus de temps pour innover plutôt que de se laisser prendre par des tâches de base qui consomment beaucoup de temps.

#2 – Bâtissez une culture axée sur les résultats

Pour créer une culture axée sur les résultats, commencez par fixer des objectifs clairs. Une fois ces objectifs en place, donnez à vos développeurs un accès complet à tous les outils disponibles et l’autonomie nécessaire pour manager leurs processus afin de les atteindre.

Un horaire de travail flexible peut permettre une culture axée sur les résultats qui limite le stress du monde moderne et augmente la productivité. La plupart des emplois de développeur n’exigent pas que les travailleurs soient dans un bureau tout le temps, alors pourquoi ne pas donner de la flexibilité à votre équipe ?

Les développeurs n’en font pas nécessairement plus en restant assis sur une chaise plus longtemps.

Les employés apprécient de pouvoir définir leurs horaires. Avoir le contrôle de leur temps et de leur lieu de travail permet des sentiments d’autonomie. Gardez à l’esprit que le travail basé sur la connaissance et la réflexion ne s’alignent pas nécessairement avec huit heures de production : Les développeurs n’en font pas nécessairement plus en restant assis sur une chaise plus longtemps.

#3 – Prévenez le stress à long terme qui mène à l’épuisement professionnel

Bien que le surmenage ne soit pas toujours le problème, il contribue à l’épuisement professionnel. En tant que leader, il est essentiel de donner l’exemple et de montrer qu’il est normal de prendre du temps pour se ressourcer.

En savoir plus sur le leadership

Conformément à l’état d’esprit axé sur les résultats mentionné ci-dessus, l’industrie s’éloigne d’horaires stricts de 9h à 17h. Selon le rapport Gartner 2021 Digital Worker Experience Survey, 43 % des répondants ont déclaré que les horaires de travail flexibles les aidaient à être plus productifs.

Les développeurs devraient être en mesure de mettre en cohérence leurs besoins personnels avec ceux de leur travail. Démontrer cela en tant que leader crée un précédent qui aide votre équipe à trouver un équilibre dans sa propre vie.

La prévention de l’épuisement professionnel maintient votre équipe en bonne santé physique et mentale et, en fin de compte, améliore la productivité. Cette productivité conduit à une plus grande innovation et aide l’entreprise à se développer à mesure que votre équipe se concentre sur la création d’expériences positives pour les utilisateurs finaux.

L’importance d’avoir une philosophie qualité dans l’environnement Agile

Le 27 septembre 20224 septembre 2022 par mopertodans agile, experience sharingLaisser un commentaire

Cet article passe en revue les principales différences entre la qualité interne et externe et insiste sur l’importance d’avoir une philosophie de qualité dans l’environnement Agile.

The importance of having a quality philosophy in the agile encironment

https://www.agilequalitymadeeasy.com/post/the-importance-of-having-a-quality-philosophy-in-the-agile-environment-david-tzemach par David Tzemach

Les différences entre qualité interne et externe

Pour comprendre le vrai sens de la qualité, vous devez faire la distinction entre qualité interne et externe :

La qualité externe fait référence à ce que le client voit lorsqu’il interagit avec le logiciel. Un exemple de mauvaise qualité externe est une interface utilisateur non intuitive qui nécessite une navigation complexe pour utiliser une fonction simple.
La qualité interne fait référence à tous les problèmes non visibles pour le client qui ont un impact sur la maintenabilité et la stabilité du système, tels que la conception du code et la couverture des tests.

Quel type de qualité est le plus important ?

Les deux sont importants, en supposant que l’équipe a le temps, les ressources et les connaissances nécessaires pour s’occuper des deux.

Mais que se passe-t-il lorsque vous devez livrer rapidement et que vous devez en choisir un ?

Il n’y a pas de réponse définitive, car chaque type présente des avantages et des inconvénients. D’expérience, un système de forte qualité interne peut être livré même avec une faible qualité externe (nous voyons cela tout le temps dans l’industrie du logiciel). Cependant, un système de faible qualité interne rendra presque impossible la construction d’une qualité externe élevée. Comment pouvez-vous construire un système qui repose sur des fondations défaillantes ?

Qu’est-ce qu’une philosophie de qualité et pourquoi en avez-vous besoin ?

Dans le cadre de tout projet de développement (Agile ou autre), l’organisation doit déterminer le niveau de qualité qu’elle s’attend à délivrer au marché et à ses clients. Le niveau de qualité doit être dérivé de la philosophie de qualité.

La philosophie de qualité est le niveau acceptable de tolérance du projet pour les écarts de qualité (par exemple, la dette technique, la faible couverture de code, etc.) et les problèmes rencontrés après la livraison des produits.

À chaque extrémité du spectre de la philosophie de la qualité, nous avons une tolérance élevée pour la mauvaise qualité et une faible tolérance pour la mauvaise qualité.

Tolérance élevée pour la mauvaise qualité

L’équipe est censée livrer les produits le plus tôt possible, quelle que soit la qualité des livrables.

Cela inclut la fourniture d’éléments présentant des problèmes de qualité importants (par exemple, les tests ne passent pas, plusieurs bogues sont connus, etc.) et même sans tests terminés. C’est parce que la philosophie de qualité de l’organisation est de battre sur les délais la concurrence à tout prix et de combler les lacunes manquantes par la suite.

Faible tolérance pour la mauvaise qualité

L’équipe est censée livrer des produits sans compromettre leur qualité, qui est censée être au plus haut niveau possible. Pour ce faire, les équipes de développement réduisent le nombre d’histoires utilisateur qu’elles peuvent fournir par version pour créer des infrastructures automatisées, en exécutant plus de tests et en passant une grande partie de leur temps à s’assurer que chaque fonctionnalité est produite avec la meilleure qualité possible.

Flux et vitesse

Comme vous pouvez le constater, la philosophie de qualité organisationnelle affecte considérablement le flux de travail et la vitesse de livraison. Par conséquent, elle doit être communiquée aux équipes d’ingénierie, car elle a un impact substantiel sur leur travail quotidien.

Notez que même si votre entreprise a une tolérance élevée pour la mauvaise qualité, cela ne signifie toujours pas que vous pouvez livrer des produits de mauvaise qualité à vos clients.

Cependant, cela permet à l’équipe de réduire la couverture des tests (d’un montant acceptable), de prendre plus de risques et d’investir moins dans la qualité « externe » car la qualité interne reste non négociable.

Être un Scrum Master ou un membre de l’équipe efficace implique inévitablement d’avoir des conversations difficiles.

Sujets sensibles et fort niveau émotionnel

Respirez et préparez-vous

Définissez l’intention

Soyez inclusif

Soyez présent

Soyez flexible

Ralentissez

Cultivez un « espace courageux »

Conclusion

Petit rappel: Développez la productivité et l’innovation avec des groupes de toutes tailles grâce aux Liberating Structures !

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

WordPress:

Les rétrospectives présentent de belles opportunités pour les membres de l’équipe de reconnaitre d’une manière authentique et sincère les efforts des autres personnes au cours du sprint passé.

Improving organizational culture through retrospective recognition par Kiron Bondale

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

WordPress:

Tous les projets ne sont pas adaptés aux approches agiles. Des critères bien pensés peuvent vous aider à déterminer si vos projets sont de bons candidats agiles.

Is your project suitable for agile practices? par Bonnie Biafore

Pouvez-vous obtenir le bon personnel ?

Les ressources ont-elles une profondeur de connaissances appropriée ?

Le Sponsor a-t-il un état d’esprit Agile ?

L’équipe peut-elle être co-localisée (physiquement ou virtuellement) ?

Existe-t-il une synergie entre les membres de l’équipe business et technique ?

Le produit peut-il être construit (et livré) de manière itérative ?

Utilisez-vous d’autres critères pour déterminer si un projet est candidat à une approche agile ?

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

WordPress:

J’espère vous rencontrer (virtuellement) nombreuses et nombreux 🏝⛵️⚓️🌊🌬pour partager ce retour d’expérience !

Nous y aborderons de nombreux aspects de ce programme à travers une rétrospective Agile

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

WordPress:

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

WordPress:

Le Thème retenu pour cette première édition est :《Ensemble, prenons un peu de recul sur l’état de l’Agilité en 2023.》

PIAF 2023, c’est quoi ?

Que va t-on partager ?

Le manifeste Agile a déjà plus de 20 ans

Voici de quoi nous permettre de parler d’agilité, d’hybride, et de partager des retours d’expériences…

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

WordPress:

Quelle que soit la façon dont votre équipe coordonne son travail, il est important que de tels événements ne soient pas perçus comme une perte de temps par l’équipe ou par les principales parties prenantes.

Petit retour sur 7 précédents billets au sujet des Daily Scrum meetings

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

WordPress:

Quels sont les bénéfices à avoir des délais bien définis ?

On schedule par Seth Godin

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

WordPress:

Et cette vidéo, plus longue et en français, entre dans les détails de ce qu’est Scrum Professionnel

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

WordPress:

Il existe une variété infinie de projets, cependant seulement 3 approches sont utilisées par la plupart des équipes qui développent des WBS.

How do you breakdown your work? par Kiron Bondale

Bien qu’il existe une variété infinie de projets, j’ai trouvé 3 approches utilisées par la plupart des équipes qui développent des WBS.

Une approche axée sur les livrables

Une approche axée sur les phases

Une approche axée sur la responsabilité

Sondage auprès des professionnelles et professionnels du management de projet

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

WordPress:

Lorsque le travail n’est pas terminé dans le sprint, que faites-vous ?

When Work Isn’t Finished In the Sprint, What Do You Do? par Joel Bancroft-Connors

Réponse courte : Je ne le fais pas.

Pourquoi ne ré-estimez-vous pas ?

Doit être utilisable

Le code pourrit

Ne prenez pas de raccourci

Le tout s’équilibre

Ne le faites pas

Enfin, profitez-en pour poser la question suivante

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

WordPress:

En 2003, Barry Boehm et Richard Turner ont inventé l’acronyme C.R.A.C.K. pour nous rappeler les caractéristiques clés d’un Product Owner efficace !

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

WordPress:

Voici un billet que j’ai trouvé très intéressant sur la réelle valeur des story points et les raisons pour lesquelles ils créent des conflits dans vos projets Agiles.

Qu’est-ce qu’un Story Point ?

Comment les story points sont-ils utilisés dans les sprints ?

Pourquoi les story points peuvent-ils être sujets à controverse ?