Savez-vous ce que signifie Agile pour votre organisation ?
Savez-vous que faire pour devenir plus agiles ?
Vous sentez-vous empruntés face à la terminologie ?
Avez-vous entendu parler de marques Agiles comme Scrum et SAFe® sans savoir ce qu’elles signifient ?
Savez-vous qui impliquer dans le développement de votre approche Agile ?
Une partie clé des transformations culturelles dans lesquelles Melanie Franklin est impliquée est le désir de devenir plus agile. Un problème fréquent dans toutes ces transformations est la confusion autour de ce qu’est Agile et sa réelle signification pour l’organisation.
Dans ce webinaire, Melanie Franklin revient sur l’essentiel, expliquant les différents mots clés Agiles, les principes de travail Agile et comment cela se traduit dans les processus et un modèle de cycle de vie. Elle différencie le développement, le projet de mise en œuvre et la gestion de changement pour un travail Agile efficace. Melanie Franklin utilise aussi des exemples pour montrer comment Agile peut être appliqué à toutes sortes d’initiatives et pas seulement informatiques.
Plus de la moitié de toutes les équipes agiles ne sont pas colocalisées, chaque personne étant à moins de 30 mètres de toute autre. Si les équipes utilisent aveuglément des approches qui assument la collocation, elles pourraient échouer. Pour éviter l’échec, comprenez d’abord la sorte d’équipe que vous avez et les données que vous pourriez devoir rassembler. Ces données fourniront la base de l’approche de votre équipe aux pratiques agiles.
Nous entendons souvent les gens décrire leurs équipes comme colocalisées, distribuées, ou dispersées. Malheureusement, trop peu de personnes se mettent d’accord sur la signification de ces mots. Et, même si vous avez vraiment une équipe non-colocalisée, le type d’équipe décidera du flux de travail et de la métrique dont vous avez besoin.
Votre équipe colocalisée pourrait être assise dans une pièce, la salle de travail de l’équipe. Une salle d’équipe encourage les gens à travailler ensemble, essaimer, travailler par paires, ou se regrouper comme nécessaire.
Trop peu d’équipes ont des salles d’équipe. Cependant, les membres d’équipe sont suffisamment près les uns des autres à une distance de 15 à 30 mètres pour pouvoir facilement se retrouver pour poser des questions, collaborer quand nécessaire et décider que faire en tant qu’équipe.
Cela demande à un adulte environ une seconde pour parcourir un mètre. Donc 15-30 mètres en environ 15-30 secondes. Si tous les membres de votre équipe sont plus distants que cela, vous avez une forme d’équipe distribuée.
Quand cela nécessite plus de 30 secondes pour poser une question, nous avons tendance à reporter la question à plus tard. Cela signifie que nous restons scotchés sur un problème, ou pire, nous passons à une autre tâche de travail. Nous augmentons notre WIP (Work In Progress), le Travail en Cours. Quand nous augmentons notre WIP, nous faisons passer moins de choses a finies (Done) par nous-mêmes et en tant qu’équipe.
Si les membres de votre équipe sont répartis sur un même étage à une distance de plus de 30 mètres, vous avez une équipe distribuée. Se déplacer à pied sur un même étage est bien meilleur que de devoir prendre l’escalier ou un ascenseur.
Si les membres de votre équipe sont sur des étages différents même dans un même bâtiment, ils font partie d’une équipe distribuée.
Équipes Satellites : La majeure partie de l’équipe ensemble, une ou deux personnes à distance
Les équipes satellites ont la plupart des membres de leur équipe à l’intérieur d’un rayon de 15-30 mètres. Une ou deux autres personnes se sentent comme si elles « tournaient » en orbite autour de la plus grande partie de l’équipe.
Nous voyons beaucoup ceci quand les développeurs et le propriétaire de produit sont dans un même bureau et que les testeurs sont à un autre étage, dans un autre bureau, ou même dans un autre pays.
Livre sur Amazon
Des équipes satellites semblent travailler comme « des bandes à part ». Parce que les membres d’équipe unis travaillent ensemble tous les jours, ils partagent l’information comme une équipe colocalisée le fait. Trop souvent, ils oublient de partager l’information avec les gens qui ne sont pas physiquement là.
Loin des yeux peut vraiment être loin de la pensée.
Parfois, des membres de l’équipe se regroupent dans bureaux ou emplacements. C’est l’équipe clusters.
Équipe Grappes (Clusters) : Les membres de l’équipe travaillent par deux ou trois
Parfois, nous voyons les développeurs ensemble dans un espace, les testeurs ensemble dans un espace différent à plus de 30 mètres des développeurs et le propriétaire de produit pourrait être sur un autre étage.
L’équipe est composée de plusieurs grappes de personnes qui travaillent ensemble dans leur petit groupe mais peu entre grappes.
Dans ce cas, les développeurs sont un cluster, les testeurs sont un autre clusteret le propriétaire de produit est un satellite. Nous appelons toujours cette équipe une équipe cluster.
Votre équipe pourrait être un cluster si les gens qui sont assis près les uns des autres représentent des fonctions différentes. La clef est qu’un certain groupe des gens se rassemble en un cluster et un autre groupe en un emplacement (cluster) différent.
Les équipes clusters ont tendance à être plus conscientes de leur tendance à devenir des bandes à part. Elles trouvent souvent des façons de collaborer pour voir le travail avancer de manière plus fluide.
Il y a une troisième sorte d’équipe, la dispersée ou équipe de nébuleuse.
Équipes de type Nébuleuse : Chacun est éloigné de tous les autres
L’avantage de l’équipe « de type nébuleuse » est que chacun a conscience de travailler à distance des autres.
Si chacun dans votre équipe travaille de son domicile ou d’un café, votre équipe est dispersée. Peut-être chacun est-il dans un bureau séparé de tous les autres. Indépendamment de l’emplacement, chaque membre d’équipe est éloigné des autres de plus de 15-30 mètres.
Quand chacun est séparé de tous les autres, l’équipe a moins de tendance de développer des « bandes à part ». D’un autre côté, il pourrait être beaucoup plus difficile de collaborer sur le travail et de le compléter (le faire évoluer vers « Fini » / Done).
Les équipes de type nébuleuse ont un aspect positif significatif: elles savent qu’elles doivent créer un espace de travail virtuel auquel chacun ait un accès équitable.
Considérez la réalité de votre équipe distribuée
Indépendamment du type d’équipe que vous avez, considérez de traiter l’équipe comme si elle était une nébuleuse. Assurez-vous que chacun ait accès à tout le code, tests et outils dont les membres de l’équipe ont besoin.
Créez un tableau qui dresse la carte du flux de travail (workflow) à travers l’équipe.
Quand je travaille avec des équipes non-colocalisées, je leur demande de dresser la carte de leur flux de valeur.
Qui amorce le travail ?
Qui prend la suite du travail?
Que font-ils avec ce travail ?
Quand le travail se bloque-t-il, se trouve-t-il dans un état d’attente ?
Après que l’équipe ait dressé la carte du flux de son travail, je lui demande d’additionner les temps de cycle. Le temps de cycle est la durée nécessaire pour que le travail passe à travers les divers états plus les temps d’attente pour être complété.
Une fois que l’équipe voit son flux de valeur et mesure son temps de cycle, elle peut se poser ces questions
Chacun dans l’équipe est-il dédié seulement à cette équipe, ou d’autres tâches les occupent-il brusquement ?
Chacun dans l’équipe a-t-il accès à la zone de travail de toute l’équipe : le code, les tests, les outils collaboratifs, quoi que ce soit dont l’équipe ait besoin pour faire son travail ?
Que devrions-nous faire pour créer plus d’occasions de collaboration ?
Votre équipe pourrait avoir d’autres questions basées sur le flux de valeur et le travail en cours visualisé dans le tableau.
Résolvez les problèmes de votre équipe
Beaucoup d’équipes distribuées ont de longs temps de cycle et trop de travaux en cours (Work In Progress – WIP). La première étape vers une solution pourrait être de devoir créer un tableau et limiter le WIP de l’équipe.
Quand les équipes limitent leur WIP, elles commencent à voir les divers problèmes dans leur équipe. Dans mon travail avec des équipes distribuées, je rencontre souvent ces problèmes :
Les membres d’équipe ne travaillent pas que pour cette équipe. Ils travaillent pour leur manager.
L’équipe n’a pas l’infrastructure suffisante pour collaborer.
L’équipe n’a pas des heures de recouvrement (horaire) suffisantes pour collaborer.
Mes recommandations sont d’abord d’identifier votre type d’équipe. Avez-vous un type d’équipe qui supporte le travail que vous voulez compléter ?
Ensuite, dressez la carte du flux de valeur et mesurez le temps de cycle de votre équipe. Voyez comment le travail circule dans votre équipe et combien de temps cela prend à votre équipe pour finir le travail et délivrer de la valeur à un utilisateur.
Finalement, commencez à évaluer les possibilités de collaboration de votre équipe.
Une fois que vous savez tout cela, votre équipe peut décider comment créer un projet Agile qui réussira.
partagez ce billet avec vos amis, collègues et relations professionnelles
J’aide une organisation à passer d’un management de projet prédictif Waterfall à Agile. Cela a mené à bien des discussions sur les bénéfices de Agile. En sus des bénéfices évidents de réponse plus rapide à des circonstances changeantes, la participation continue du client/business et un retour sur investissement accéléré, je veux ajouter l’honnêteté.
L’honnêteté se réfère à être honnête sur combien nous pouvons compléter dans les délais alloués. Je sais que ceux qui s’opposent à Agile se plaignent qu’il n’y ait aucune planification ou rapport mais ce n’est pas vrai et la planification qui est faite dans Agile nous donne une visibilité beaucoup plus claire de ce qui est créé, souvent à un niveau très granulaire. Cela fournit l’honnêteté sur ce que le business peut attendre suite au projet et donc l’honnêteté sur les bénéfices probables qui seront réalisés.
FDF est partenaire de DantotsuPM
Honnêteté du planning
La planification est centrée sur la production ou l’accomplissement, plus basée sur les activités. Cela mène à une honnêteté inhérente sur ce qui est créé, depuis les exigences au niveau epics aux user stories (histoires d’utilisateur) individuelles et exigences plus détaillées ensuite jusqu’aux activités spécifiques nécessaires pour livrer ces exigences.
Les équipes utilisent des techniques pour décomposer chaque livrable à réaliser en activités spécifiques, ce qui leur permet de vérifier entre elles qu’elles ont les ressources, compétences et information facilement accessibles pour leur permettre de produire le livrable. De nouveau, il y a de l’honnêteté pour savoir si vraiment tout le nécessaire est en place pour faire le travail.
Honnêteté du développement
Ce niveau granulaire de détail mène à une compréhension beaucoup plus claire du temps exigé pour développer chaque composant. Pour des produits petits, spécifiques, le temps dont on a besoin pour aller du projet initial à la revue, corriger et finir le produit peut être calculé.
Ceci est imposé par le travail en sprints souvent de seulement quelques semaines de durée. L’heureux effet collatéral de ces “décompositions de produit” est la clarté de savoir exactement ce qui va être créé avant que ce ne soit créé.
Les équipes peuvent plus facilement voir dès les premiers sprints combien de travail ils peuvent réaliser et ainsi il y a une plus grande honnêteté dans ce qu’ils promettent de livrer dans les sprints ultérieurs.
Honnêteté d’implication du business
Les propriétaires de produit (aussi connu comme des Ambassadeurs du Business) peuvent clairement voir ce que l’équipe prévoir de livrer. Cela rend plus facile pour eux de partager leurs propres idées sur les besoins devant être inclus et se projeter sur comment ils peuvent s’impliquer dans le design, le développement et les tests de chaque composant.
Cette honnêteté s’étend aussi au déploiement ou le travail de management des changements que le business devra réaliser pour se préparer à travailler de la nouvelle façon. Les pièces spécifiques de travail sont plus faciles à comprendre que les plus grands regroupements d’exigences. Il y a ainsi une meilleure compréhension de quels changements doivent être apportés “au travail comme d’habitude” (Busines as usual) pour adopter les livrables que l’équipe développe.
Melanie Franklin (Co-Chair of the Change Management Institute UK Chapter)
Comme vous pouvez le constater, je suis fan d’utiliser Agile pour diriger une large variété d’initiatives et j’aide beaucoup d’organisations à développer leur transformation Agile.
Mélanie a dédié la dernière vingtaine d’années à aider ds organisations de toutes sortes à construire leur capacité de changement et d’adaptation.
CertYou est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Ce manuel est un guide indispensable pour que les coachs et les agilistes puissent identifier les techniques (pratiques, stratégies et cycle de vie) les plus efficaces en fonction de leur situation et moins efficaces dans d’autres contextes. Ce recueil de conseils se base sur l’expérience de centaines d’organisations confrontées à des situations souvent similaires aux vôtres.
Il y a des centaines de livres qui ont été écrits sur #Agile et #Lean. Alors pourquoi un de plus?
La plupart de ces livres se concentrent sur un sous-ensemble de tout ce qui est nécessaire pour développer et délivrer de bout en bout des solutions d’une manière Agile. Il s’avère difficile d’élaborer une approche cohérente en croisant ou juxtaposant ces pratiques. De plus, il arrive que les conseils de certains de ces livres soient contradictoires et parfois peu documentés. Ils sont souvent fondés sur l’expérience et la réalité mais seulement à partir de quelques réussites et dans un contexte bien particulier probablement différent du votre.
Quand nous manageons des projets en une approche de livraison prédictive, l’identification des dépendances et leur suivi est fait lors de la grande planification amont en utilisant les activités après décomposition des tâches et la sagesse collective des membres de notre équipe et des principales parties prenantes. Si un changement majeur d’approche ou de portée de solution est identifié, on considère les impacts et nouvelles dépendances lors de l’analyse de la demande de changement.
Matchware est partenaire de DantotsuPMVoici le diagramme du Modèle Scrum
Mais sur ces projets qui suivent un cycle de vie adaptatif, cela devient un peu plus compliqué. Étant donné la nature émergente des exigences et du design, nous sommes seulement capables de voir les dépendances dans la lumière « des phares » de notre équipe et ceux-ci pourraient seulement nous montrer les deux semaines à venir de travail. Une équipe pourrait avoir considéré “Toutes les dépendances ont-elles été identifiées et capturées ?” dans sa définition de Ready (prêt) mais cela ne signifie pas toujours qu’il est possible de satisfaire cette dépendance dans les temps.
CertYou est partenaire de DantotsuPM
Nous nous efforçons toujours de construire une équipe qui possède toutes les compétences et l’autorité nécessaire pour délivrer la pleine portée du produit ou du projet.
Mais parfois, nous avons besoin d’un expert du sujet pour un petit sous-ensemble des fonctionnalités du livrable et si nous n’identifions pas ce besoin assez tôt, nous ne serons pas capables de livrer ces fonctions au bon moment. De plus, construire une équipe complète dans de grandes organisations est souvent difficile car il y a des équipes en place avec lesquelles travailler pour construire et livrer des fonctionnalités spécifiques, mais elles ne seront pas nécessairement disponibles à la demande.
Une façon de réduire les risques associés aux dépendances qui seraient identifiées trop tard est une combinaison de revue des User Stories avec une planification avancée.
La revue des User Stories fournit une occasion de rassembler les partenaires clés de livraison et de contrôle pour considérer les histoires à un haut niveau avec le Product Owner et l’équipe de développement. Cette revue donne aux partenaires externes une chance d’indiquer quelles histoires les intéressent et aidera l’équipe à savoir avec qui elle doit se synchroniser pour compléter l’une de ces histoires. En fonction de combien ces histoires remontent dans la Story Map, ils comprendront comment elles pourraient devoir être engagées. Les membres de l’équipe peuvent aussi commencer à identifier et capturer les interdépendances entre plusieurs histoires individuelles pour aider le Product Owner dans la priorisation du Product Backlog.
Comme les histoires avec des dépendances commencent à remonter dans le product backlog priorisé, l’équipe peut activement entrer en contact avec les partenaires externes pour demander leur participation un sprint ou deux à l’avance.
La planification est une activité récurrente dans les approches adaptatives car sans cela, un partenaire externe dont votre équipe a besoin va probablement répondre par le vieux cliché : “un manque de planification de votre part ne constitue pas un cas d’urgence de ma part.”
partagez ce billet avec vos amis, collègues et relations professionnelles
Les Daily Standups peuvent devenir des corvées superficielles, chacun passant simplement à travers les rubriques. C’est le travail du ScrumMaster que de s’assurer que cela n’arrive pas et que ces réunions restent utiles pour chaque membre de l’équipe.
Épuisé par la corvée du Daily Standup ?
Avec ces 5 idées, le ScrumMaster peut activement aider les Daily Standups à rester efficaces et encourager la communication, la transparence et une livraison efficace de valeur.
Les Daily Standups sont principalement un outil de synchronisation pour des équipes de développement. Elles y discutent des progrès réalisés et planifient leur travail pour les vingt-quatre heures suivantes. Le ScrumMaster en est le facilitateur et d’autres parties prenantes du projet peuvent aussi venir écouter.
Les équipes sont libres de décider elles-mêmes de comment elles veulent utiliser ces réunions de quinze minutes, mais cela met une responsabilité complémentaire sur les épaules du ScrumMaster qui doit s’assurer que la réunion produit toujours deux résultats critiques :
L’équipe se concentre sur les aspects cruciaux à la progression, y compris la façon de dynamiter les obstacles et elle est capable de mettre en place un plan de travail réaliste pour la journée.
Le propriétaire de produit, le Product Owner, et les parties prenantes peuvent y puiser l’information essentielle sur les progrès réalisés vers la production de code utilisable qui apporte de la valeur aux utilisateurs.
Voici 5 façons pour le ScrumMaster de mieux faciliter les Daily Standups pour atteindre ces objectifs et encourager la communication, la transparence et la livraison efficace de valeur.
CertYou est partenaire de DantotsuPM
1. Contrôlez fermement le travail en cours
Scénario : Une développeuse indique au daily standup qu’elle prévoit de travailler sur une nouvelle histoire et ne voit pas d’obstacle immédiat. Le ScrumMaster demande si l’histoire sur laquelle elle travaillait hier est finie et elle répond que l’histoire a été mise en attente en raison d’une question d’architecture technique qu’un architecte doit examiner, donc elle planifie de travailler sur autre chose.
Les points de blocage ne sont pas toujours explicitement exprimés causant de longues périodes d’attente improductives.
C’est une bonne chose que le ScrumMaster ait posé une question pour découvrir le fait qu’une histoire est en attente et qu’il y a des obstacles qui n’ont pas été discutés ou adressés sur celle-ci. Maintenant, le ScrumMaster peut suggérer que lui et la développeuse rencontrent immédiatement un architecte pour accélérer l’élimination du point de blocage pour que le travail de priorité la plus élevée puisse continuer.
Faire ceci permet de contrôler le travail en cours (Work In Progress : WIP) en se focalisant sur achever le travail qui a été engagé avant de commencer quelque chose de nouveau. Cela rappelle aussi à l’équipe de tenir le compte de combien d’histoires sont engagées en même temps et à garder le WIP sous une certaine limite qui aura été agréée avec l’équipe.
2. Encouragez la collaboration sur des activités quotidiennes
Scénario : Un testeur au Daily Scrum dit qu’il continuera à tester l’histoire débutée hier et qu’il n’y a aucun obstacle. Le ScrumMaster demande si ce test peut être achevé avant la fin de la journée et si oui ce qu’il fera ensuite. Le testeur se rend compte qu’il a oublié de mentionner qu’il prendra probablement une nouvelle histoire à tester après le déjeuner, mais il n’en a pas encore discuté avec le développeur.
Sur quelle pièce de travail, le testeur va-t-il essayer d’éliminer les imperfections quand il en aura fini avec l’actuelle ?
Le ScrumMaster s’est assuré que cette collaboration critique prend place quand on passe d’une histoire à la suivante. Le bénéfice est que, parce que l’équipe entière sait ce qui arrive, quelqu’un qui connaît de cette nouvelle histoire peut fournir l’information.
Il est essentiel que le ScrumMaster s’assure que le développement et les tests collaborent chaque jour et discutent des histoires comme elles sont mises en œuvre et testées.
3. Identifiez tous les points de blocage ou blockers
Scénario : L’administratrice de la base de données dit qu’elle a fini une histoire hier et en a pris une autre qu’elle prévoit de continuer aujourd’hui et qu’il n’y a aucun obstacle. Mais le ScrumMaster se rappelle qu’il y avait eu quelques échanges d’email récents entre cette administratrice de base de données et l’expert du sujet chez le client pour clarifier certains points sur cette histoire, donc le ScrumMaster
Il faut trouver la personne qui saura dégager le chemin.
demande si ces questions ont été résolues. L’administratrice de base de données reconnaît qu’il reste des choses à clarifier pour cette histoire et qu’il y a en réalité des blockers sur lesquels le ScrumMaster ou quelqu’un d’autre pourraient aider.
Il est important pour le ScrumMaster de suivre à la trace toutes les questions non résolues et de s’assurer que l’équipe en discute ouvertement pour que la personne qui en a la capacité puisse aider à les éliminer rapidement.
L’avantage que cette facilitation amène est que l’équipe devient plus attentive aux questions en attente de réponses et se rappelle d’utiliser le ScrumMaster pour aider à déminer ces questions.
4. Aidez l’équipe à décider de la priorité des problèmes
Scénario : Une équipe travaille sur des problèmes de production et de développement de nouvelles fonctionnalités, ce qui les force à répartir leur travail entre ces deux domaines. Le ScrumMaster pose des questions sur les problèmes majeurs de production: Sont-ils bien priorisés ? Sont-ils répartis équitablement dans toute l’équipe, ou au moins planifiés correctement pour chacun ? Et impacteront-ils la finalisation des nouvelles fonctionnalités prévues ? L’équipe se rend compte qu’elle ne parviendra pas à compléter toutes les nouvelles fonctionnalités, donc les membres discutent de la priorisation avec le propriétaire de produit pour obtenir son avis.
Le ScrumMaster devrait continuellement aider l’équipe à manager les attentes avec le côté business et mieux négocier le contenu du développement pour les prochains sprints. Ainsi, le côté métier/business sait toujours où en sont les choses et n’est jamais pris par surprise à la fin d’un sprint.
5. Soutenez des formats alternatifs de Daily Standup
Scénario : Au lieu d’utiliser le format de Daily Standup classique et répondre à trois questions (Qu’avez-vous fait hier ? Que ferez-vous aujourd’hui ? Qu’est-ce qui bloque la progression ?), l’équipe décide de discuter chaque histoire une par une, en faisant parler ceux qui sont directement impliqués. Malheureusement, cela implique que ces réunions prennent plus de temps…
Pendant la rétrospective suivante, le ScrumMaster suggère que l’équipe regarde les façons de ramener leur Daily Standup à quinze minutes. Le ScrumMaster commence aussi à surveiller l’horloge pendant les Daily Standup, aidant l’équipe à apprendre comment communiquer leurs partages plus efficacement.
Les Daily Standups risquent fort de se muer en travail de ménage superficiel
Parce que c’est la réunion de l’équipe et qu’ils devraient auto-organiser pour décider ce qu’ils veulent, le ScrumMaster devrait soutenir des formats alternatifs de Daily Standup si l’équipe pense que c’est ce qui aura du sens pour ses membres. Mais il reste toujours que la priorité majeure du ScrumMaster est de s’assurer que les objectifs du standup sont aussi atteints.
Les Daily Standups peuvent se muer en travail de ménage superficiel, chacun survolant simplement les questions. C’est le travail du ScrumMaster de s’assurer que cela ne se produise pas et que les réunions restent utiles pour chacun. Avec ces 5 idées, le ScrumMaster peut activement aider les Daily Standups à être efficaces et atteindre leur but.
partagez ce billet avec vos amis, collègues et relations professionnelles
Bien sûr, nous ne chercherons pas forcément à atteindre des rôles de coach ou instructeur, mais il est je pense utile de comprendre le cheminement (voir ce billet Octo sur le Shu-Ha-Ri)
Toutes les certifications, hormis la première (DA), font l’objet de tests avec des prérequis clairement établis.
Je comprends totalement la résistance de quelques membres d’équipe à la participation aux réunions Scrum quotidiennes, les Daily Scrum. Et pourtant, elles sont fort utiles si bien menées.
Je comprends totalement la résistance de quelques membres d’équipe à la participation aux réunions Scrum quotidiennes, les Daily Scrum. Je n’aime pas non plus les réunions. Mais, certaines réunions sont utiles et justifient l’investissement de notre temps. Je mets les réunions Daily Scrum bien-dirigées dans cette catégorie.
Dans cet article, je partage avec vous comment je traite quatre objections fréquentes à la participation au Daily Scrum. Je partage ensuite quelques attributs d’un Daily Scrum bien-mené pour qu’il n’y ait plus aucune objection à participer.
4 objections fréquentes
1. Nous parlons déjà beaucoup
Pas de temps à « perdre » alors que nous discutons déjà énormément.
La première objection au Daily Scrum est qu’une personne insiste sur le fait que les membres d’équipe parlent déjà fréquemment l’un avec l’autre et donc le Daily Scrum est une surcharge inutile.
Quand j’entends cette objection, j’y résiste en reconnaissant que les membres de l’équipe parlent vraiment fréquemment en effet l’un avec l’autre. Mais rarement parlent-ils tous ensemble.
Le Daily Scrum fournit cette opportunité. Pour beaucoup d’équipes, c’est l‘unique fois chaque jour où chaque membre d’équipe est capable de parler à tous les autres membres de l’équipe.
2. Rien d’important n’est jamais discuté
Une deuxième objection commune au Daily Scrum vient de membres d’équipe qui estiment que des Daily Scrum sont inutiles parce que rien d’important n’y est jamais discuté.
Repositionnez les attentes
On ne priorise pas la discussion pour discuter des plus importants problèmes en premier.
La première chose je fais quand je suis face à cette objection, est de poser une attente appropriée sur ces réunions avec l’opposant. Je suis très clair sur le fait que je ne m’attends pas à ce que quelque chose d’important soit abordé chaque réunion. Certains Daily Scrum s’avèrent vraiment être assez inutiles, ceux où chacun a réalisé un progrès convenable mais sans quoi que ce soit de remarquable hier et personne n’a de question sur le travail du jour.
Mais, la plupart des Daily Scrum remontent vraiment quelque chose d’utile pour l’équipe. Et l’idée est que les nombreux Daily Scrum où des choses importantes sont discutées compensent les réunions moins fréquentes où rien d’important n’est discuté.
Déterminez si l’objection est valide
La deuxième et plus importante chose que je fais quand j’entends cette objection, est de considérer si elle est recevable. Elle peut l’être. S’il en est ainsi le Scrum Master devrait la prendre en compte comme un indicateur que les réunions pourraient être améliorées.
Prenons le temps de considérer objectivement si la question est pertinente.
Les erreurs fréquentes qui rendent cette objection valable incluent laisser des participants blablater hors sujet, laisser la réunion durer trop longtemps, ou avoir une bande d’individus qui ne sont pas vraiment une équipe. Cette dernière erreur arrive quand « une équipe » est composée d’individus travaillant sur des projets totalement sans rapport.
3. Ne pourrions-nous pas juste le faire par email ?
Certains membres d’équipe ne font pas d’objection au concept d’engager avec leurs coéquipiers quotidiennement, mais au lieu de cela, objectent à en faire une réunion. Ils demanderont souvent d’abandonner le Daily Scrum en faveur d’un email quotidien de chaque personne adressant les mêmes questions habituelles du Daily Scrum.
J’ai rarement vu ceci fonctionner. Le plus grand problème est que la plupart des personnes ne lisent pas les emails. Ou, si elles le font, c’est un jour ou deux plus tard. Cela rend l’équipe moins réactive aux problèmes.
De plus, mener un Daily Scrum par email perd tous les bénéfices de la discussion dans l’instant présent qui devrait faire partie des réunions.
Et avec des outils comme Slack et semblables ? Vous penseriez peut-être que ma réponse serait la même que pour l’email. Cependant, j’ai vu des équipes mener avec succès l’équivalent de réunions Daily Scrum en utilisant Slack.
Je ne sais pas si c’est la nouveauté de tels outils ou quelque chose de fondamentalement différent entre la messagerie instantanée et l’email. Je ne favorise toujours pas de remplacer l’interaction vivante d’un Daily Scrum avec un équivalent Slackpour la majorité des équipes. Mais pour certaines équipes, particulièrement celles qui sont fortement géographiquement distribuées, cela semblent vraiment marcher de manière adéquate.
4. Les réunions durent trop longtemps
Une quatrième et finale objection que vous entendrez consiste en ce que les réunions durent trop longtemps. Naturellement, vous voudrez prendre cette plainte au sérieux si vos réunions prennent plus longtemps que la norme de quinze minutes prescrites par presque tous les partisans de Scrum.
Mais si vos réunions finissent bien dans la limite des quinze minutes, j’ai constaté que la meilleure réponse à cette plainte est de demander à tout opposant combien de temps il pense serait approprié.
Vous obtiendrez une réponse utile particulièrement si vous incluez quelques-uns des bénéfices de la réunion en posant la question. Par exemple, vous pourriez demander, “Combien de temps pensez-vous serait approprié chaque jour pour nous tenir tous synchronisés, éviter les problèmes de communication, fournir de la visibilité sur ce que fait chacun d’entre nous, identifier et corriger des erreurs, construire la confiance et fournir un sentiment d’accomplissement ?”
CertYou est partenaire de DantotsuPM
7 Attributs d’un Daily Scrum bien mené
Les conseils ci-dessus aideront à surmonter les objections les plus communes que des membres d’équipe peuvent avoir à participer au Daily Scrum. Encore mieux, serait de conduire ces réunions si bien que les membres d’équipe les valorisent. Voici sept attributs d’un Daily Scrum bien mené.
1. Tenez les réunions chaque jour au même horaire et endroit
Vous voulez rendre ces réunions aussi faciles que possible. Pour la plupart des équipes, cela signifient les tenir à la même heure et au même endroit à chaque fois.
2. Débutez la réunion à l’heure
Je suis plus à l’heure que qui que ce soit d’autre. J’ai une fois dû me raisonner d’appeler un docteur quand j’ai réalisé que j’aurais une minute de retard à son cabinet.
Mais je reconnais tout de même qu’arriver quelques minutes en retard à une réunion qui dure toute une journée n’est pas une bien grande affaire. Être cinq minutes en retard à une réunion de huit heures représente 1 % du temps de la rencontre.
Mais être en retard à un Daily Scrum est une affaire beaucoup plus importante. Si les réunions commencent 5 minutes en retard chaque jour, les membres d’équipe qui sont arrivés à l’heure auront perdu plus de 20 heures sur l’année à attendre que la réunion puisse commencer.
3. Respectez la limite de 15 minutes
Il y a une raison pour laquelle beaucoup d’équipes conduisent les Daily Scrum en se tenant debout : Cette position nous aide à rester conscient du temps et facilite les réunions brèves.
4. Identifiez les problèmes mais ne les résolvez pas pendant la réunion
Une bonne pratique commune est de discuter (et avec bon espoir résoudre) des problèmes immédiatement après la réunion. Idéalement cela peut être fait par le sous-ensemble de l’équipe nécessaire pour aborder ces problèmes; les autres membres d’équipe sont alors encouragés à retourner à leurs bureaux.
5. Gardez les participants sur le sujet
La plupart des équipes suivent l’approche d’avoir chaque personne exposer ce qu’ils ont accompli depuis la dernière réunion, ce qu’ils feront avant la réunion suivante et tout problème les ralentissant.
Toute discussion hors de ces sujets devrait être sévèrement limitée.
6. Les règles sont rappelées par l’équipe entière, pas seulement le Scrum Master
Quand le Scrum Master est le seul à imposer les règles de l’équipe lors des réunions, la réunion semble être tenue pour le Scrum Master. Cela ressemble à rapport d’activités où chaque participant fournit le statut seulement au bénéfice du Scrum Master.
7. L’équipe complète et seulement l’équipe participe
Chacun dans l’équipe devrait participer aux Daily Scrum. On devrait permettre à des externes à l’équipe d’observer la réunion. Ils devraient être découragés de contribuer à la discussion pendant la réunion à moins qu’un membre d’équipe ne lui pose une question courte.
Une fois que l’on conclut un Daily Scrum, mais avant que les participants ne se dispersent, beaucoup d’équipes demanderont aux observateurs s’ils ont des questions ou commentaires. Le Scrum Master ou un sous-ensemble de l’équipe peuvent rester et adresser ceux-ci. La clef est que ces commentaires d’observateur restent à l’écart du Daily Scrum.
Quelle est votre expérience ?
Les membres d’équipe peuvent sans aucun doute avoir des objections autres que les quatre les plus communes que j’ai adressées ici. Et il y a certainement des choses complémentaires importantes pour un Daily Scrum bien mené que les sept attributs essentiels que j’ai décrits.
Quelle est votre expérience ? Quelles objections avez-vous entendu et comment les avez-vous surmontées ? Partagez s’il vous plaît vos idées dans les commentaires.
partagez ce billet avec vos amis, collègues et relations professionnelles
Depuis tout jeune, on nous apprend à ne rien laisser dans notre assiette !
Une mesure fréquemment utilisée d’une équipe agile est si les membres d’équipe finissent tout ce qu’ils ont prévu dans l’itération.
Il n’y a rien mal à évaluer si une équipe est capable à la fin de terminer ce qu’elle pensait pouvoir faire. Mais on devrait s’attendre à ce qu’aucune équipe ne finisse tout à chaque fois.
Ce serait peu réaliste et cela amènerait les équipes à moins s’engager pour pouvoir tout livrer sans prendre de risque.
Matchware est partenaire de DantotsuPM
Des attentes excessives peuvent entrainer des dysfonctionnements
Considérez une équipe dont le patron (le PDG) leur a dit que s’il leur arrivait d’échouer à tout finir, il “prendrait des actions correctives, jusqu’à et incluant probablement l’arrêt brutal du projet.”
Cette équipe ne va pas aller chercher une masse excessive de travail dans ses itérations. Les membres essayeront d’en choisir suffisamment pour ne pas être traités de paresseux, mais pas trop pour ne pas risquer de ne pas tout faire.
CertYou est partenaire de DantotsuPM
Une cible appropriée
Je trouve qu’un bon objectif pour une équipe est de finir tout ce qu’ils disent qu’ils feront environ 80% du temps. C’est un bon degré de prévisibilité pour le business sans être impossible à tenir par les équipes.
Pour être vraiment clair, une bonne équipe agile devrait finir 100% de ce qu’elle prévoit dans 8 itérations sur 10. Je ne dis pas qu’une équipe devrait finir 80% de son travail prévu à chaque itération. C’est très différent.
80% du temps dans la cible est déjà très bien.
Tout faire à chaque fois sera impossible pour des équipes fréquemment interrompues. Si une partie significative du travail de votre équipe est de répondre rapidement aux problèmes, vous pouvez vouloir vous donner une cible de pourcentage inférieur.
Ne le planifiez pas si vous ne pensez pas que vous le réaliserez
En essayant de finir 100% de son travail, 80% du temps, l’équipe devrait ressentir qu’ils vont réussir tout en comprenant, avec réalisme, qu’ils ne le feront pas à chaque fois.
J’aime y penser comme analogue au basketteur lançant le ballon. Le joueur ne devrait pas lancer le ballon à moins qu’il ne pense qu’il marquera le panier. Mais, même le meilleur basketteur comprend que tous ses lancers ne peuvent entrer dans le panier.
Un bon basketteur peut réussir 40 à 50% de ses lancers. Ce n’est pas suffisamment de prévisibilité pour la plupart des équipes, voici pourquoi je recommande de viser les 80%.
Quelle est votre expérience ?
Où en est votre équipe sur compléter ce qu’elle a dit qu’elle ferait ? Partagez s’il vous plaît vos idées dans les commentaires ci-dessous.
partagez ce billet avec vos amis, collègues et relations professionnelles
Dans notre papier blanc Can Agile (SAFe) Be Interfaced With Waterfall? , nous avons identifié trois domaines majeurs qui ont dû être adressés pour qu’un scénario de programmes corrélés avec des approches de management différentes ne cause pas de dramatique accident de train (SAFe).
Le manque de visibilité cause de nombreux accidents sur la route comme dans les projets
Le manque de transparence cause des malentendus et des conflits.
Cependant, générer de la transparence a un coût.
Trouver le bon équilibre qui adapte le coût et les contraintes contractuelles est un objectif de chaque programme compliqué. Produire de la transparence exige un jeu spécifique de comportements.
Plusieurs des techniques les plus communes pour générer de la transparence
#1 – Le Contrat
Spécifiez ce qui peut et doit être partagé dans le contrat. Énoncer spécifiquement ce qui peut être partagé réduira le niveau de friction quand un programme demande de l’information d’un autre. Les types d’information qui devraient être mises en commun incluent : risques, problèmes, plans, architecture, échéanciers et le code qui marche (important pour les tests et le développement continu). Les sujets exclus de partage dans le contrat resteront opaques et seront basés sur des opinions.
#2 – Un Plan construit conjointement
Les leaders du programme et techniques de chaque programme doivent suivre les sessions de planification des autres. La participation augmentera la conscience du flux de travail, fera remonter des risques et leur permettra de travailler conjointement sur des risques et communiquer les dépendances en temps réel.
Matchware est partenaire de DantotsuPM
#3 – Des Cérémonies communes
Toute technique agile contient des réunions périodiques (de souvent appelées cérémonies). Les cérémonies incluent typiquement la planification, les réunions de synchro, les démonstrations et les rétrospectives. Ces réunions fournissent une plate-forme pour partager l’information ce qui réduit les risques de malentendus et de suppositions.
#4 – Des Ateliers de mûrissement des exigences et de design
Collecter les exigences et décider des approches de conception fourniront une plate-forme pour apprendre la culture et les personnalités des personnes dans les deux programmes tout en développant aussi une compréhension commune du problème qu’elles adressent.
#5 – Des Modèles de design
L’adoption de modèles de design et autres standards fournit une langue commune et une approche pour que les deux programmes puissent partager l’information et la compréhension.
Facile ET difficile à la fois
une plus grande transparence comme base de relations et de travail
Les étapes deux à quatre sont des actions relativement simples que les deux programmes peuvent prendre pour établir une plate-forme pour la transparence et commencer ensuite à agir sur cette plate-forme. Dans presque chaque scénario, la première étape : le contrat, est l’éléphant dans la pièce. Si le contrat n’est pas écrit pour faciliter la transparence, il n’y a aucune chance que cela arrive.
partagez ce billet avec vos amis, collègues et relations professionnelles
Les projets agiles sont basés sur le concept que livrer une solution imparfaite au business le jour promis est plus important que livrer une solution parfaite en retard.
Avec Agile, tenir vos promesses sur quand quelque chose sera disponible pour être utilisé en production est au cœur de la réalisation de bénéfices. Chaque élément fourni, même s’il a un nombre minimal de fonctionnalités peut résoudre un problème métier. Focalisez votre équipe sur faire utiliser leur livrable en production, en sachant qu’ils pourront ajouter davantage de fonctionnalités plus tard.
Il y a une fausse idée répandue qui est que ceux travaillant dans des équipes Agiles ne planifient rien.
Alors que les compétences de planification y sont plus importantes que dans l’approche prédictive « en cascade » (PRINCE2 ®) pour les projets parce que :
La planification est plus fréquente
La planification est faite en collaboration, impliquant chacun qui contribue au projet
Les plans y sont un mécanisme essentiel de suivi du progrès
QRP est partenaire de DantotsuPMaux fausses croyances sur Agile
Pour ces raisons, les compétences de planification sont critiques au travail Agile efficace. La planification détaillée du projet de bout en bout au début ne fait pas partie Agile. Au lieu de cela, il y a la planification fréquente et la re-planification pendant tout le cycle de vie du projet. Quand un élément de la solution est livré au business, le focus se porte sur la planification de la livraison suivante.
Objectifs de la planification
Pour respecter l’importance de planification, j’encourage mes équipes à se mettre d’accord sur un jeu commun d’objectifs pour leurs sessions de planification.
Utilisez ceux-ci pour débuter avec votre équipe :
Assurons-nous que nous livrons une solution utilisable et de valeur
Assurons-nous que nous n’avons rien oublié
Donnons la priorité au travail le plus important en premier
Allouons le travail aux meilleurs de l’équipe pour le faire
Clarifions l’ordre/le séquencement pour réaliser des économies d’efforts
Créons un visuel qui permette aux autres de voir ce que nous faisons et quand afin qu’ils puissent aligner leur travail avec le nôtre
Utilisons ce visuel pour fournir un suivi facile de notre progression sans devoir écrire de rapport d’avancement
CertYou est partenaire de DantotsuPM
Ordre du jour de la planification
Supportez ces objectifs en définissant comment va se dérouler chaque session de planification.
J’encourage mes équipes à utiliser un ordre du jour standard pour tous les événements de planification.
Utilisez cet ordre du jour type pour encourager votre équipe à faire de même :
Examiner les résultats de notre session de brainstorming préparatoire.
Appliquer les critères de priorisation pour créer une liste agréée de travail pour ce sprint
Définir ensemble qui va construire et qui va tester le résultat.
Chaque personne crée son propre échéancier pour le sprint en s’assurant que les must have ne dépasse pas les 60 % du travail.
Chacun effectue un contrôle croisé de son échéancier avec la personne testant son travail.
Réserver le temps nécessaire dans son agenda pour réaliser le travail
Se mettre d’accord sur comment vous partagerez le progrès avec l’autre
Matchware est partenaire de DantotsuPM
Pour plus d’astuces sur l’application des pratiques de travail Agile dans la vraie vie, abonnez-vous au bulletin de Melanie ou visitez son site Web.
partagez ce billet avec vos amis, collègues et relations professionnelles
L’approche Agile signifie que les idées sont très tôt dans leur développement distribuées au business pour qu’ils les essayent. Leurs retours sont essentiels au concept et pour ajouter plus de fonctionnalités.
CertYou est partenaire de DantotsuPM
Mais…Je commence à se demander combien d’entre nous sont vraiment prêts pour ces retours. Après tout, c’est souvent un mélange d’éloges et de critiques, qui penche trop souvent vers la critique :
Il ne fait pas ce que nous avons dit !
Où est la fonctionnalité X ?
J’ai pensé que ça allait remplacer Y mais maintenant il ne semble pas que ce soit le cas ?
Il ne se connecte pas avec Z donc nous aurons besoin d’un processus manuel pour enregistrer ces données!
Ceci vous semble-t-il familier ? Il est difficile d’aller chercher des réactions, mais si ce doit être utile, je dois le faire dans un état d’esprit de curiosité.
Curiosité
La curiosité est une belle qualité plutôt qu’un vilain défaut.
Je dois commencer le processus avec un véritable intérêt pour ce que je vais entendre. Et pour obtenir les retours les plus utiles, je dois entendre des perspectives différentes. J’ai besoin de courage pour dépasser mes contacts habituels et trouver un ensemble le plus diversifié possible de voix. Après tout, plus la personne donnant les réactions a une expérience et un contexte différents des miens plus ils vont possiblement poser des yeux neufs sur la question.
Je viens de finir de lire l’excellent livre par Michelle Obama où elle fait ces remarques “la similarité amène davantage de similarité, jusqu’à ce que vous fassiez un effort réfléchi pour la neutraliser.” Elle parlait des recruteurs à la Maison Blanche mais c’est vrai de tous ceux avec qui nous travaillons.
Mes efforts pour neutraliser la similarité impliquent un effort conscient de reconnaître mes expériences et rechercher des personnes qui en ont de différentes. À moins que je ne sois très honnête avec moi-même sur mon contexte, mes accomplissements, mon chemin de vie, il est ardu de reconnaître l’existence de quoi que ce soit de différent.
Cherchez votre opposé
Beaucoup de mes clients essaye d’encourager cette auto-évaluation sur les biais cognitifs inconscients, qui semble vraiment être la tendance. Ce que je retiens de cela est “cherchez l’opposé” car semble être une bonne place pour commencer :
Je cherche des personnes qui ont la moitié de mon âge.
Je cherche des personnes sans diplômes.
Je cherche des personnes qui ont changé d’industries de multiples fois.
Je cherche des personnes qui ont travaillé pour le même employeur pendant des décennies.
Je cherche des personnes qui ont vécu et ont travaillé dans des pays différents.
Comme nous changeons de saison, je veux vous soumettre le défi suivant. Sortez et faites-vous de nouveaux contacts !
FDF est partenaire de DantotsuPM
Commencez à discuter avec de nouvelles personnes
Au lieu de regarder votre montre, engagez la conversation avec vos voisins.
Faites l’effort conscient d’engager la conversation avec des personnes que vous ne connaissez pas dans la file d’attente pour déjeuner. Demandez-leur où elles travaillent et ce qu’elles font. Allez dans une autre partie de votre bâtiment et présentez-vous à de nouveaux collègues. Demandez à être conférencier externe dans d’autres réunions d’équipe pour pouvoir partager ce sur quoi travaille votre équipe avec d’autres parties de votre société.
Engagez la conversation avec des clients et des fournisseurs et demandez-leur quelles sont leurs priorités et défis pour la saison prochaine et dites-leur sur quoi vous travaillez. Découvrez s’il y a les zones d’intérêts communs et une chance de collaborer.
Un printemps d’opportunités !
Je sais que tout cela semble un travail difficile mais chacun a ce nouveau printemps à l’esprit et c’est une belle occasion de parler de ce qui a été réalisé récemment et ce qui vient ensuite.
Autrement dit vous avez déjà une entrée en matière, alors sortez et utilisez-la.
partagez ce billet avec vos amis, collègues et relations professionnelles
Demandez votre copie gratuite de ce très sympathique et complet poster Scrum et montrez-le à vos collègues et amis.
Cette affiche peut être un outil d’apprentissage (par exemple lors de la lecture du guide Scrum) et un outil permettant à un ScrumMaster d’expliquer Scrum à l’organisation, au responsable produit ou à l’équipe de développement.
Une seule demande par personne est acceptée. Expédition aux États-Unis et en Europe uniquement. Vous serez informés par e-mail une fois le poster expédié.
Et voici la bande son en anglais dans cette vidéo
CertYou est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
L’utilisation d’une approche Agile est pertinente pour tout type de changement, et pas seulement pour les changements technologiques.
Melanie le précise parce que, trop souvent, on a l’impression que Agile ne s’applique qu’aux projets des nouvelles technologies.
Les principes et techniques d’Agile ont été largement adoptés dans l’ensemble de la communauté informatique, mais les initiatives de restructuration des entreprises, de changement de localisation, d’acquisition et de rationalisation des processus bénéficient toutes d’Agile.
En effet, Agile est une façon de travailler qui permet de décomposer un objectif en petits étapes, chaque pas (ou Sprint en approche Scrum) menant à une réalisation qui peut être utilisée, davantage développée et construite.
Je ne sais pas pour vous, mais j’ai remarqué que nous indiquons rarement une date ou raison de péremption sur nos besoins utilisateurs et autres user stories…
Hors, il n’est pas si rare qu’après une certaine date, jalon projet ou événements internes ou externes, certains des besoins précédemment exprimés (et toujours en attente dans le product backlog) ne soient plus d’actualité.
Qu’en pensez-vous et comment traitez-vous ce problème ?
Est-ce en amont, en indiquant sur la user story une date ou les raisons pour lesquelles elle pourrait devenir inutile ?
Est-ce périodiquement lors de grands « ménages » saisonniers ?
Ou bien, serait-ce plutôt de manière opportuniste, lors par exemple d’un changement d’application de gestion du product backlog ? Ou d’arrivée d’un nouveau product owner, scrum master… ?
CertYou est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Je vous l’accorde volontiers, il ne s’agit pas avec Agile d’oublier que la complexité est bien réelle ni de l’ignorer…
Mais, il faut savoir commencer petit puis apprendre en marchant si l’on veut tirer rapidement bénéfice des avancées même modestes.
Par exemple, vous pouvez trouver acceptable d’avoir des paramétrages codés en dur dans la première version du logiciel, ou bien des capacités réduites de personnalisation, ou encore un seul profil/persona utilisateur…
Ou des choix de coloris limités pour vos premières productions.
CSP est partenaire de DantotsuPM
Devrions-nous adopter certaines des approches de « triage » utilisées dans les services des urgences des hôpitaux pour définir nos MVPs ?
Livre sur Amazon
Darria Long, médecin urgentiste, explique les principales leçons tirées des urgences de l’hôpital sur la gestion du stress, du chaos et de la vie.
Le Dr. Darria Long Gillespie est un médecin d’urgence formé à Yale et Harvard, auteur du livre à succès « Mom Hacks ».
partagez ce billet avec vos amis, collègues et relations professionnelles
Avec l’essor massif de l’Agilité dans les organisations et plus particulièrement de la méthode Scrum, un nouveau rôle est apparu : Scrum Master.
Et avec ce rôle de nombreuses questions:
Peut-il développer ?
Est-il chef de projet ?
Est-il le responsable des développeurs ?
Comment s’interface-t-il avec les utilisateurs et le Product Owner ?
Quelles sont ses missions ?
Cette vidéo devrait vous permettre de faire le tri entre les mythes et les réalités qui entourent ce rôle.
En bonus vous repartez avec quelques outils bien pratiques dans votre rôle quotidien de Scrum Master si vous l’êtes et vous comprendrez mieux ce rôle si vous ne l’êtes pas !
CertYou est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
DantotsuPM.com 