Le Daily Scrum n’a qu’un seul but : Inspecter les progrès vers l’objectif de sprint en réfléchissant à l’apprentissage d’hier. Ensuite, si le besoin s’en fait sentir, les développeurs adaptent leur plan pour atteindre l’objectif de sprint. Bien que la théorie puisse être généralement acceptée, passer de l’idée à la pratique est plus difficile. L’un des problèmes récurrents est la popularité continue des « 3 questions du Daily Scrum» selon le Guide Scrum 2017.
Réfléchissons à la raison pour laquelle répondre à ces questions obsolètes influence négativement l’équipe Scrum.
Le but du Daily Scrum
Le but du Daily Scrum est clairement décrit dans le Guide Scrum, aucune supposition n’est nécessaire :
« Le but du Daily Scrum est d’inspecter les progrès vers l’objectif de sprint et d’adapter le backlog de sprint si nécessaire, en ajustant le travail prévu à venir.
Guide téléchargeable gratuitement
Le Daily Scrum est un événement de 15 minutes pour les développeurs de l’équipe Scrum. Pour réduire la complexité, il a lieu à la même heure et au même endroit chaque jour ouvrable du Sprint. Si le Product Owner ou le Scrum Master travaillent activement sur des éléments du Sprint Backlog, ils participent en tant que développeurs. »
Par conséquent, le Daily Scrum est un événement important pour l’inspection et l’adaptation, géré par les développeurs, et les guidant pour les prochaines 24 heures sur leur chemin vers la réalisation de l’objectif de sprint. Le Daily Scrum est également l’horizon de planification le plus court dans Scrum et donc très efficace pour guider les efforts de l’équipe Scrum : se concentrer sur le résultat.
Le problème avec les 3 questions quotidiennes
Cependant, cette noble idée est entachée d’une habitude répandue : Centrer la réunion quotidienne autour de la réponse à trois questions
Qu’est-ce que j’ai fait hier ?
Que vais-je faire aujourd’hui ?
Y a-t-il un obstacle ?
Initialement, ces trois questions du Daily Scrum ont été ajoutées au Guide Scrum 2017 comme exemple de la façon dont les membres de l’équipe Scrum peuvent inspecter les progrès vers l’objectif de sprint. Cependant, ces trois questions sont rapidement devenues synonymes de Daily Scrum. Depuis lors, il s’agissait de répondre à ces trois questions, de transformer le Daily Scrum en une sorte de réunion de rapport d’état d’avancement, avec des développeurs faisant la queue pour « répondre à ces trois questions » au Scrum Master, au Product Owner, ou peut-être même à une partie prenante.
Malheureusement, les « trois questions du Daily Scrum» plaisent à de nombreux praticiens : Elles sont simples, efficaces et créent une routine réconfortante. Cependant, en tant qu’équipe Scrum, nous nous soucions moins de détailler notre travail précédent et de justifier pourquoi nous méritons un chèque de paie à la fin du mois.
Au lieu de cela, nous voulons comprendre si nous atteindrons l’objectif de sprint. Si les progrès de l’équipe Scrum sont douteux, compte tenu des développements récents et des apprentissages, nous voulons prendre des mesures pour nous remettre sur les rails. Toute forme de rapport de situation est une simple distraction et un gaspillage à cet égard.
Scrum en tant que pratique est axée sur les résultats
Il ne s’agit pas de maximiser le nombre de tickets obtenus pendant le Sprint. Au lieu de cela, en tant qu’équipe, nous sommes intéressés par atteindre l’objectif de sprint.
Il existe d’innombrables façons d’exécuter votre Daily Scrum sans tomber dans cette routine des 3 questions. Par exemple, parcourez le tableau et déterminez ce qui doit être fait pour déplacer les billets les plus proches de « terminés » sur la ligne d’arrivée.
Livre sur Amazon
Consultez les pratiques d’utilisation des liberating structures pour faciliter le Daily Scrum.
S’il vous plaît, faites-vous une faveur et évitez de transformer votre Daily Scrum en une session de reporting ennuyeuse.
Comment gérez-vous vos Daily Scrum ? S’il vous plaît, partagez vos conseils et astuces dans les commentaires.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
partagez ce billet avec vos amis, collègues et relations professionnelles
Il existe plusieurs techniques différentes pour mener le processus d’estimation. Cet article décrit ces techniques, leur pertinence et leur praticité dans les projets Agiles.
Les estimations traditionnelles sont basées sur des unités de jours ou d’heures (dans de rares cas, je l’ai même vu utilisé pour estimer des histoires basées sur 20, 30 et 45 minutes), et l’équipe les utilise pour estimer leurs histoires et leurs tâches. À mon avis, c’est bien si cela aide l’équipe dans le processus de transition et même si elle veut l’adopter comme technique d’estimation. J’espère que vous ne tenez pas compte des récits selon lesquels les estimations traditionnelles ne conviennent pas à Agile car elles sont rarement exactes pour tous ceux d’entre vous qui pensent autrement.
Taille de T-shirt
La taille des t-shirts est une excellente technique d’estimation que j’utilise dans les organisations au début de la transformation. Vous ne pouvez pas utiliser de story points avec certaines équipes, car les membres de l’équipe alignent les story points sur des heures d’effort. Cela conduit à une confusion supplémentaire.
La taille du t-shirt permet aux équipes de surmonter ce problème car cette technique d’estimation n’est pas numérique. Cela permet aux équipes Agile de travailler avec quelque chose de plus facile à comprendre. Cela supprime la précision implicite d’une valeur numérique et libère l’équipe pour penser de manière abstraite à l’effort qu’elle doit investir dans chaque histoire.
Le processus de base de cette technique est relativement simple à utiliser
Un jeu de cartes représentant une taille spécifique est distribué horizontalement sur une table. Les tailles sont divisées en Extra Small (XS), Small (S), Medium (M), Large (L) et Extra Large (XL).
L’équipe ajoute chaque user story sous la carte de taille appropriée.
Une fois que toutes les histoires sont triées sur la base d’une discussion collaborative, l’équipe approuve leur sélection ou conduit un autre cycle de débat sur les histoires qui ont révélé une grande incertitude.
Vote par points (dot voting)
Le vote par points est une autre technique d’estimation relative. Il permet aux équipes Agile de voter leurs préférences parmi un ensemble d’éléments en plaçant simplement des points sur des éléments (par exemple, des fonctionnalités, des histoires, des obstacles, etc.) qui, selon elles, devraient avoir une priorité plus élevée que les autres éléments. Le nombre de points détermine le niveau de priorité. Plus il y a de points, plus la priorité de l’élément est élevée.
Le vote par points est une technique d’estimation très efficace car il permet à tous les membres de l’équipe d’affecter la priorité des éléments de manière égalitaire. Tous les membres de l’équipe ont un nombre égal de votes (représentés par des points), qu’ils peuvent répartir entre les éléments dans le cadre du processus d’estimation.
Par exemple, l’équipe a dressé une liste de huit points lors de la réunion rétrospective. Ils doivent maintenant restreindre la liste aux éléments de valeur la plus élevée. Pour ce faire, chaque membre de l’équipe reçoit un nombre égal de points (entre 3 et 5) pour voter sur les éléments.
Remarque: Ils peuvent mettre tous les points sur un élément ou les répartir entre différents éléments.
Le processus d’utilisation de haut niveau de cette technique d’estimation comprend les phases suivantes
Phase 1 : Facilitation, examen et vote
Tous les articles sont placés dans un endroit accessible pour permettre aux membres de l’équipe de voter.
Tous les éléments sont examinés et compris par toutes les parties prenantes.
Chaque membre de l’équipe reçoit un nombre égal de points (j’utilise généralement cinq points).
Chaque membre de l’équipe est invité à voter. Chacun des membres place des points sur les éléments en fonction de son jugement.
Une fois le processus d’estimation terminé, les articles sont classés du plus fort au plus faible nombre de points.
Approuvez avec l’équipe le résultat du vote.
Phase 2 : Ajustements et nouveau vote (facultatif)
Si l’équipe n’est pas complètement satisfaite du résultat (comme cela arrive souvent…), vous devez suivre les étapes suivantes pour optimiser le résultat :
Organisez les éléments en trois groupes pour représenter les priorités faibles, moyennes et élevées.
Passez en revue avec l’équipe les histoires de chaque groupe.
Lancez un nouveau cycle de vote pour tous les points de priorité la plus élevée.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
partagez ce billet avec vos amis, collègues et relations professionnelles
Même si je ne suis pas personnellement un grand fan de SAFe, une nouvelle version recèle toujours son lot de nouveautés dont nous pouvons toutes et tous apprendre : Voici donc SAFe 6.0 !
Cette version représente une avancée significative dans la façon dont les entreprises intègrent les pratiques SAFe dans le travail quotidien, font perdurer le changement et obtiennent les avantages d’une véritable agilité business. SAFe 6.0 comprend de nombreuses nouvelles pratiques pour supporter les dernières tendances technologiques et business, y compris comment accélérer le flux de valeur et étendre SAFe à travers toute l’organisation à d’autres fonctions business.
Et, bien sûr, ces nouvelles directions se reflètent dans les mises à jour du didacticiel, de l’apprentissage en ligne et des ressources SAFe. Leading SAFe®, l’un des cours les plus populaires de Scaled Agile, est désormais disponible en français.
Pour tous les détails, lisez l’article What’s new in SAFe 6.0. Et n’oubliez pas de regarder les vidéos d’annonce de lancement de SAFe 6.0 pour en savoir plus sur SAFe Studio, SAFe 6.0 et d’autres nouveaux produits pour vous aider dans votre parcours SAFe.
Ê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
Soyez présent et appréciez pleinement cette opportunité.
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 !
Visitez le site en Français
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 !
partagez ce billet avec vos amis, collègues et relations professionnelles
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
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.
Guide téléchargeable gratuitement
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.
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.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
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 !
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
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
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.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
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.
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
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.
partagez ce billet avec vos amis, collègues et relations professionnelles
« 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.
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
Livre sur Amazon
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
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.
partagez ce billet avec vos amis, collègues et relations professionnelles
« 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.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
partagez ce billet avec vos amis, collègues et relations professionnelles
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 ?
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
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
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.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
partagez ce billet avec vos amis, collègues et relations professionnelles
L’un des clichés à propos de Scrum est qu’il est « facile à comprendre mais difficile à maîtriser ».
Guide téléchargeable gratuitement
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 timeboxingde 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.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
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.) »
partagez ce billet avec vos amis, collègues et relations professionnelles
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
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 ?
Brisez 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.
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.
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.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
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é.
partagez ce billet avec vos amis, collègues et relations professionnelles
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
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.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
partagez ce billet avec vos amis, collègues et relations professionnelles
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 ?
« 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 ?
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
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.
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.
CSP DOCENDI est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.
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.
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.
partagez ce billet avec vos amis, collègues et relations professionnelles
Depuis lors, il s’agissait de répondre à ces trois questions, de transformer le Daily Scrum en une sorte de réunion de rapport d’état d’avancement, avec des développeurs faisant la queue pour « répondre à ces trois questions » au Scrum Master, au Product Owner, ou peut-être même à une partie prenante.
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.
DantotsuPM.com 