Qu'est-ce que le Succès pour un Scrum Master ?

Aujourd'hui, c'est votre premier jour. Ce n'est probablement pas la première fois que vous endossez le rôle de Scrum Master, mais aujourd'hui c'est différent. Vous faites face à une nouvelle équipe, une nouvelle organisation. Un set de challenges totalement différent.

Vous l'avez déjà fait auparavant, mais pas dans ce contexte, pas avec cette équipe et pas dans cette organisation. Comment vous adaptez-vous ? Comment relevez-vous le challenge de cette nouvelle équipe ? Quels outils de votre expérience passée pouvez-vous utiliser pour vous aider à réussir dans ce contexte ? Vous n'avez pas pris note des outils que vous avez utilisés dans le passé, n'est ce pas ?

Nous avons tous été dans une situation similaire, ou nous le serons dans le futur. Si nous voulons réussir en tant que Scrum Master, nous devons créer notre propre approche pour les différentes équipes et organisations avec lesquelles nous allons travailler. Heureusement, nous n'avons pas besoin de créer cette approche et concevoir nos outils de Scrum Master seul. Nous avons plein de ressources utiles qui nous aident à créer notre propre boîte à outils de Scrum Master. Des excellents livres pratiques tels que #Workout de Jurgen Appelo, en passant par les classiques comme Peopleware de DeMarco et Lister, aux plus focalisés sur le coaching comme Coaching Agile Teams de Lyssa Adkins. Mais la meilleure façon d'apprendre est de discuter avec de nombreux Scrum Masters, avec des expériences diverses. De cette diversité d'expériences, nous pouvons construire nos propres approches et obtenir l'inspiration d'en essayer des différentes jusqu'à trouver celle qui fonctionnera dans notre contexte particulier.

Un grand éventail d'approches différentes est une ressource primordiale pour les Scrum Masters car nous ne ferons pas face aux mêmes situations encore et encore, mais au lieu de cela nous ferons constamment face à des nouvelles situations presque tous les jours. Lorsque l'on participe au daily stand-up après qu'un nouveau membre se soit joint à l'équipe, ou que l'on planifie un Sprint juste après une démo ratée, nous avons besoin d'accéder à cette boite à outils étendue et inventer des pratiques, techniques et approches innovantes et engageantes pour aider nos équipes et nos organisations à réussir.

Pour pouvoir aider les Scrum Masters à créer leur propre approche, nous avons collecté de nombreuses perspectives différentes dans le podcast de "Boite à Outils de Scrum Master" et nous en avons sélectionné quelques-unes ici pour que vous puissiez vous y référer dans le futur. Vous trouverez ci-dessous une liste de 15 outils et approches que des Scrum Masters du monde entier utilisent. Des Scrum Masters expérimentés expliquent comment ils définissent et mesurent leur propre succès personnel en tant que Scrum Master, et partagent leurs apprentissages sur comment l'atteindre. De la gestion des parties prenantes à comment améliorer ses compétences de coaching et aider l'équipe à atteindre un rythme soutenable, ces leçons viennent de nombreuses années d'expérience et vous aideront à améliorer votre performance en tant que Scrum Master.

Nous avons également ajouté quelques mises en garde et avertissements à prendre en compte. L'objectif : vous aider à réussir en tant que Scrum Master.

C'est parti.

La plus importante des leçons apprises par des Scrum Masters expérimentés

Comment mesure-t-on le succès en premier lieu ? La leçon la plus commune partagée par les Scrum Masters expérimentés est : Pour atteindre le succès, vous devez tout d'abord définir ce qu'est le succès et évaluer le chemin pour y parvenir. Chaque Scrum Master a une manière légèrement différente de faire, mais tous le font. Vous trouverez ci-dessous des exemples concrets et des questions que vous pouvez utiliser pour mesurer votre propre succès en tant que Scrum Master.

1. Définissez votre façon de mesurer le succès, et suivez votre propre développement juste comme vous suivriez le développement de l'équipe. Jeff Kosciejew a listé trois questions qu'il suit pour évaluer son propre succès :

1. L'équipe a-t-elle livré un logiciel prêt pour la production ce Sprint ?
2. Est-ce que tout le monde était heureux et fier de ce qu'ils ont réalisé ?
3. Avons-nous amélioré notre manière de travailler ? (c.à.d avons-nous produit plus de valeur que dans le précédent Sprint ?)

Cette approche d'avoir vos propres questions en tant que Scrum Master semble être populaire parmi les autres Scrum Masters également. Dominic Krimmer a créé sa propre checklist pour évaluer sa performance en tant que Scrum Master :

1. Avons-nous une Vision d'Equipe ?
2. Avons-nous un objectif ou focus de Sprint clairement défini ?
3. Est-ce que nous gardons notre Scrum Board à jour pour rendre notre travail visible et transparent ?
4. Avons-nous un tableau de bord pour communiquer aux autres le statut de notre produit ?
5. Avons-nous des stories de bonne qualité ?

Enfin, Stefano Porro suggère une autre liste de questions :

1. L'équipe, et les membres de l'équipe, sentent-ils que leur contribution est estimée et vue comme importante ?
2. L'équipe est-elle heureuse de travailler sur ce projet ?
3. Est-ce que l'équipe, si on lui laisse le choix, voudrait encore travailler avec vous en tant que Scrum Master dans le futur ?
4. "L'indice de participation" en daily stand-up est-il au bon niveau ? (Index de participation = nombre d'interventions non sollicitées qui affectent comment l'équipe travaille.)

Les questions que vous utilisez pour mesurer votre succès ne sont pas aussi importantes que le fait que vous ayez votre propre liste de questions, ou votre propre checklist que vous suivez régulièrement pour vous aider à focaliser votre attention sur les bons sujets, ceux qui nécessitent votre attention pour développer vos compétences en tant que Scrum Master. Comme Andy Deighton l'exprime : Au début, vous pouvez ignorer votre définition du succès, mais tôt ou tard vous aurez besoin d'une boussole, une manière de mesurer votre propre développement en tant que Scrum Master Professionnel. Demandez-vous : Est-ce que j'ignore mon succès en tant que Scrum Master Professionnel ?

La plus commune des définitions du succès pour les Scrum Masters et comment l'atteindre

Quel a été le symptôme le plus commun dans la réussite de votre travail en tant que Scrum Master ? Je suis heureux que vous me le demandiez : De loin, la définition du succès la plus commune listée par plus de 30 interviewés dans le podcast était : le processus appartient à l'équipe. Cette leçon est venue sous de nombreuses différentes formes, de l'équipe s'appropriant les réunions ou cérémonies du processus Scrum, aux équipes interagissant activement avec d'autres équipes et les parties prenantes dans l'organisation. La question difficile pour les Scrum Masters est : Comment est-ce que nous aidons nos équipes à s'approprier le processus ? Voici quelques outils listés par des Scrum Masters expérimentés :

2. Soyez absent pendant quelques jours et évaluez comment l'équipe s'est approprié le processus et les réunions. Matt Dominici, qui a suggéré cette idée, nous dit que le niveau d'appropriation ne peut être vu que lorsque vous êtes absent. Si vous revenez de quelques jours de coupure et retrouvez votre équipe perdue, et le processus abandonné, c'est un signe clair que l'équipe n'est pas encore prête à "s'approprier" le processus. Mais ne désespérez pas, cet outil est également utile car lorsque vous revenez, vous pouvez évaluer ce qu'il manque, ou pas pris en charge par l'équipe, et vous pouvez focaliser votre attention de coaching sur ces sujets. Par exemple, si vous revenez et découvrez que l'équipe a abandonné le test de ses modifications, alors vous saurez que l'équipe a encore besoin d'aide dans la compréhension de cette partie du travail, ou manque d'outils pour les aider à intégrer le test dans leur travail quotidien.

3. Focalisez sur la définition et l'apport d'une plateforme pour votre équipe. Jeff Kosciejew capitalise sur son expérience de musicien pour expliquer comment certains instruments (ou rôles) sont là pour fournir les bonnes conditions et l'environnement permettant aux autres de réussir. Il appelle cela une "plateforme" sur laquelle l'équipe se construit. Les Scrum Masters doivent faire de même ; alors une caractéristique importante pour les Scrum Masters est d'être confortable avec le fait d'être en retrait, dans un rôle de support et de facilitation. Chaque cérémonie nécessite une approche différente pour créer cette plateforme. Dans le daily stand-up, par exemple, vous pouvez simplement sortir du cercle. Prenez du recul lorsque l'équipe discute de sujets liés à leur travail, et intervenez lorsqu'ils ont besoin de votre support, ou pour faciliter la réunion. Ce retrait physique aidera l'équipe à réaliser que vous êtes là pour eux en soutien, et les encouragera à s'approprier la réunion.

L'outil le plus utilisé par les Scrum Masters

Une question qui est dans l'esprit de chacun est : Quel est l'outil le plus utilisé par les Scrum Masters dans le monde ? Aucun doute que vous avez vos propres idées basées sur votre expérience. Mais la réponse à cette question m'a un peu surpris...

4. Ayez de nombreuses conversations en 1-to-1, et prenez des notes. Aussi simple que cela peut paraître à première vue, la conversation est l'outil le plus souvent utilisé par les Scrum Masters que nous avons interviewé. Matt Dominici explique comment il utilise les conversations comme l'outil préférentiel pour apprendre ce qui affecte l'équipe, le citant comme l'outil de choix pour mesurer la satisfaction dans l'équipe, par exemple. Les conversations sont un outil suffisamment simple, mais souvent oublié et non développé. Une manière d'améliorer vos compétences en conversation est de lire How to win friends and influence people, by Dale Carnegie, où l'auteur définit une liste claire de choses que vous devez avoir en tête lorsque vous voulez cultiver une relation avec les personnes avec lesquelles vous travaillez tous les jours. Carnegie suggère : Toujours commencer par parler de quelque chose qui intéresse l'autre personne ; soyez sincèrement intéressés par leurs points de vue ; ne commencez pas à argumenter, vous ne pouvez pas gagner. Dans un autre épisode, Tim Bourguignon nous rappelle que nous devons écrire nos idées sur tout ce qui se passe, et que prendre des notes à propos de chacune de ces conversations est un excellent moyen de se souvenir de ce que nous avons appris et d'être réfléchi dans la gestion des relations avec les personnes avec qui nous travaillons.

Tout est dans le POURQUOI

5. Aidez l'équipe à définir son objectif, pour que l'équipe puisse trouver sa propre définition du succès. Luis Gonçalves nous rappelle que d'avoir un objectif clair est une des clés de la motivation et du succès. Sans un objectif partagé, l'équipe ne peut aligner ses actions. Dans le podcast, Luis suggère un atelier spécifique à tenir avec les équipes avec lesquelles nous travaillons qui aide à définir l'objectif d'équipe. Cet atelier est inspiré du travail de Daniel Pink, duquel vous pourrez en lire plus dans Drive: The Surprising Truth About What Motivates Us.

6. Le "pourquoi" est ce qui définit le succès ; demandez toujours pourquoi avant de commencer. Dans la même ligne de pensée, Stefano Porro nous rappelle l'importance de demander "pourquoi" avant de commencer. Stefano nous raconte l'histoire de l'échec d'une équipe qui s'est focalisée sur le "comment" et qui n'a jamais vraiment réfléchi au "pourquoi" de son travail. Stefano a utilisé cet apprentissage pour changer son approche en tant que Scrum Master, et maintenant il demande toujours "pourquoi" pour s'assurer que lui et l'équipe comprennent les raisons du travail. C'est seulement en sachant pourquoi nous faisons ce que nous faisons que nous pouvons réaliser notre meilleur travail, et en tant que Scrum Master, nous devons nous assurer que cet activateur de performance d'équipe est clair.

La posture de coaching

7. Apprendre à coacher l'équipe est un des voyages les plus importants pour les Scrum Masters. Il n'y a pas de succès pour le Scrum Master à moins que l'équipe ne réussisse également. Et pour cela, nous devons apprendre à travailler avec l'équipe. Travailler avec l'équipe signifie que nous aidons constamment l'équipe, et pas en faisant le travail à sa place, en résolvant ses problèmes, ou en reprenant ses réunions. La posture de coaching est par conséquent un aspect fondamental du travail de Scrum Master. Dans un épisode bonus, Bob Marshall décrit la Communication Non Violente (CNV), une approche qui peut aider le Scrum Master avec des outils concrets qui aideront l'interaction avec les équipes. La CNV demande l'acceptation que nous ne pouvons forcer quiconque à faire quoi que ce soit, mais plutôt que nous devons nous assurer que les raisons de faire quelque chose soient claires, et acceptées. Si nous ne sommes pas d'accord sur le "pourquoi" (voir au-dessus), alors nous devons travailler sur cela en premier. La CNV est une mine d'inspiration et de direction pour l'aspirant coach dans chaque Scrum Master.

8. L'équipe avec laquelle vous avez travaillé hier n'est pas la même que celle avec laquelle vous allez travailler demain ; adaptez vos pratiques à l'étape de développement de l'équipe. Chaque équipe est en constante évolution, littéralement tous les jours. La façon dont nous travaillons avec les équipes doit aussi évoluer pour s'adapter aux étapes de développement de cette équipe. Dominic Krimmer nous rappelle les étapes de développement de groupe de Tuckman, aussi connu sous le modèle Forming, Storming, Norming, Performing. Lorsqu'on lui demande comment il traite avec les équipes dans différentes étapes de développement, Dominic explique son approche pour chacune de ces phases, et pourquoi la même recette ne peut être utilisée pour toutes les étapes. Comprendre dans quelle étape se trouve l'équipe, et quelle est la bonne approche pour cette étape est une compétence clé pour les Scrum Masters.

9. Le coaching se passe entre des adultes consentants ; obtenez le consentement avant de commencer. Dans l'esprit de la CNV, nous ne pouvons pas forcer une équipe à accepter d'être coachée. Le coaching nécessite le consentement de toutes les personnes impliquées. Steve Holyer nous demande de concevoir notre alliance de coaching avec l'équipe avant de commencer notre travail en tant que Scrum Master. C'est cet objectif partagé et cet ensemble d'attentes qui plus tard vous permettront de demander aux équipes s'ils sont toujours engagés dans cet accord initial, et de collectivement leur rappeler ce qu'ils ont explicitement accepté au démarrage de votre engagement avec eux. C'est une manière très concrète d'obtenir la permission, et de regagner leur consentement plus tard lorsque la situation sera plus tendue. Cette alliance de coaching est votre "contrat" avec l'équipe, et vous aide à refocaliser l'équipe sur l'objectif global de votre travail avec eux.

Mesurez tout

Mesurer le succès implique mesurer. Et Tim Bourguignon prend cette tâche au sérieux :

10. Mesurez tout, et gardez des notes sur tout. Tim Bourguignon explique qu'en tant que Scrum Master, nous bénéficions de "tout" mesurer”, et de garder des métriques sur tout ce que nous pouvons. De cette manière, nous avons la possibilité de regarder plus tard les tendances dans le temps. Voilà comment vous pouvez commencer :

1. Commencez par garder des notes sur tout. En réunion, après les conversations, tout le temps.

2. Mesurez tout ce que vous pouvez : les tâches complétées, le temps de cycle, les fonctionnalités, les interactions, etc.

3. Obtenez des chiffres sur tout ce que vous faites en tant que Scrum Master. Combien de fois avez-vous parlé à chaque membre de l'équipe cette semaine ? Combien de fois vous êtes-vous senti perdu, ou ne saviez-vous pas comment aller de l'avant ?

4. Regardez les tendances. Seuls les chiffres peuvent vous aider à voir les tendances. Alors mesurez et prenez du recul pour avoir une vision globale.

Bien que cela puisse sembler intimidant à prime abord, vous n'avez pas besoin de commencer avec toutes les métriques. A la place, regardez votre contexte et définissez 3 métriques que vous aimeriez suivre pour mieux comprendre la situation. Utilisez la prochaine rétrospective comme déclencheur de vos mesures. Evaluez les sujets que vous aimeriez emmener en rétrospective (ou demandez à l'équipe quel sujet elle aimerait discuter), et gardez des métriques liées à ce sujet particulier. Cela vous permettra de commencer, et aura une récompense à court-terme : vous aurez l'information dont vous avez besoin pour la prochaine rétrospective.

11. Regardez les métriques qui montrent comment le "système" se comporte pour que vous puissiez aider l'équipe à comprendre son contexte. Nos équipes existent au sein d'un contexte spécifique. Elles sont affectées par des politiques de société, par les technologies qu'elles utilisent, par l’interaction avec les autres équipes et par la culture de l'organisation. Mesurer les métriques locales de l'équipe ne vous aidera pas à comprendre comment le système global se comporte. C'est pourquoi Neil Killick suggère de regarder les métriques systémiques, telles que les métriques Lean du Temps de Cycle et du délai. Le délai vous aidera à comprendre combien de temps les exigences ou User Stories passent dans le système, alors que le Temps de Cycle vous aidera à comprendre combien de temps cela prend pour produire une User Story une fois que l'équipe a commencé à travailler dessus. Voici un exemple concret de l'utilité de ces métriques : si une équipe A complète toutes les stories dans le Sprint dans lequel elles ont été commencées, mais que le délai pour ces stories est bien plus grand (disons plusieurs mois), vous saurez que vous devrez vous focaliser sur la compréhension de ce qui empêche les stories d'atteindre l'équipe (si le retard est avant le Sprint), ou pourquoi les stories sont gardées aussi longtemps avant d'aller en production (si le retard est après que la story soit considérée comme Terminée). Dans un cas, l'équipe avec laquelle je travaillais avait des stories avec un temps de cycle moyen de l'ordre de la semaine, mais un délai de plusieurs mois. Ces métriques ont aidé le client à comprendre qu'ils devaient réduire le temps que passaient les stories à attendre d'être testées après qu'elles aient été complétées par l'équipe de développement.

Tout est dans le rythme soutenable

Scrum est ferme sur la durabilité du travail. Une phrase communément entendue dans les cercles de développement logiciel est : "Le développement logiciel est un marathon, pas un sprint". Scrum prend l'approche qu'un des objectifs pour l'équipe est de trouver un rythme soutenable. Mais comment nous, en tant que Scrum Master, savons si l'équipe travaille dans un rythme soutenable ? Il y a plusieurs réponses à cette question ; une des réponses les plus communes est que nous devrions mesurer la satisfaction dans l'équipe.

12. Mesurez la satisfaction d'équipe pour évaluer la durabilité. Andy Deighton suggère quelques outils sur le podcast que vous pouvez utiliser pour mesurer la satisfaction. Journey Lines est un outil que vous pouvez utiliser en rétrospective pour évaluer un Sprint ou une période de temps plus longue (par exemple un projet) d'une perspective individuelle ou d'équipe. Un autre outil que vous pouvez utiliser pour mesurer la satisfaction est la Happiness Door, un outil qui combine quelques autres outils avec l'objectif de mesurer la satisfaction régulièrement. Vous pouvez par exemple utiliser cette technique pour mesurer l'impact d'événements spécifiques sur l'équipe lorsqu'ils surviennent (par exemple, après un planning, une revue, ou une réunion avec les parties prenantes, etc.) La "Happiness Door" est un outil plus temps réel, conçu pour aider les équipes à réfléchir, et à réagir sur ce qu'il se passe à des moments spécifiques dans le temps. Il y a d'autres méthodes pour mesurer la satisfaction, et il y a d'autres aspects qui affectent la durabilité du travail, l'idée implicite de cette leçon est que vous pouvez mesurer la satisfaction comme un symptôme de (manque de) durabilité et orienter les méthodes sur des sujets spécifiques ou des événements qui affectent l'équipe.

A la fin, nous devons produire de la valeur pour continuer à jouer au jeu

Alistair Cockburn a introduit l'idée que le développement logiciel était un "jeu coopératif, infini” dans son célèbre livre Agile Software Development, The Cooperative Game. Utilisant la Théorie des Jeux, Alistair déclare que le développement logiciel ne se termine pas avec un projet, ou une livraison, et que l'objectif d'une équipe est de "préparer le prochain mouvement", pour qu'ils puissent continuer à jouer au jeu du développement logiciel. En pratique, cela signifie que peu importe la réussite que nous avons aujourd'hui dans ce que nous faisons, nous devons continuer à produire du logiciel de valeur, qui répond à de vrais problèmes clients et utilisateurs, pour pouvoir continuer à jouer au jeu.

13. Le succès s'agit de produire quelque chose de valeur, aidez l'équipe à mesurer la valeur produite. Il est parfaitement possible de produire du logiciel de haute qualité, d'une manière incrémentale sans produire aucune valeur. Antti Tevanlinna nous alerte sur ce fait dans l'épisode où il décrit une leçon qu'il a apprise d'une expérience : Peu importe votre niveau en production de logiciel, à la fin c'est le succès de votre produit sur le marché qui définit votre succès en développement logiciel. En tant que Scrum Master, nous devons êtes capables d'aider l'équipe à identifier si ce qu'elle produit a de la valeur. Nous pouvons faire cela en faisant interagir le Product Owner avec l'équipe, et en faisant définir et valider la valeur du logiciel que nous produisons par le client. Demander au client (ou à un représentant du client) la valeur d'un logiciel produit est un des outils que nous pouvons utiliser, mais ce n'est pas toujours possible, alors le Scrum Master doit travailler activement avec l'équipe et le Product Owner pour définir des méthodes pour mesurer la valeur du logiciel produit par l'équipe. Si vous voulez en savoir plus sur comment vous pouvez faire cela, alors les méthodes discutées dans la communauté Lean Startup sont de bonnes pistes pour commencer.

14. Scrum a une position spécifique pour la définition de Valeur ; utilisez là intelligemment. Antti Tevanlinna nous averti également : Dans Scrum, la définition de la valeur est "cachée" dans le backlog. Si l'équipe n'est pas familière avec le backlog, la vision pour le logiciel qu'elle est en train de créer sera cachée. Ce n'est pas suffisant pour une équipe de savoir sur quelles stories elle doit travailler, elle doit comprendre le contexte de ces stories. De simples questions comme: "Qu'est-ce que l'utilisateur souhaite réaliser avec cette story particulière ?" peut aider l'équipe à comprendre la raison pour laquelle elle produit une fonctionnalité particulière. Cette compréhension du "pourquoi" une story est produite sera critique pour l'équipe afin de produire leur meilleur travail. Nous, en tant que Scrum Master, devons nous assurer que l'équipe et le Product Owner conversent régulièrement au sujet du "Pourquoi" des stories, et se mettent d'accord sur une Vision pour le logiciel qu'ils produisent. Ce n'est qu'alors que nous pouvons nous assurer que la valeur n'est pas cachée dans le backlog ou dans l'esprit du Product Owner, mais qu'elle est partagée et comprise par l'équipe.

Agile s'agit simplement de la gestion (et du raccourcissement) de vos cycles de feedback

Scrum est une méthode agile qui place un accent spécial sur la longueur des cycles de feedback. Il nous demande de définir une boite de temps (le Sprint) où un cycle complet de développement est réalisé, de la découverte des exigences à la livraison en production. La raison de cet accent est que le feedback que nous obtenons à la fin de ce cycle est ce qui permet à l'équipe de continuellement s'améliorer. Mais le Sprint n'est pas le seul cycle de feedback que vous devriez regarder. Il y a plein de cycles de feedback que nous avons besoin de rendre clairs et de gérer en tant que Scrum Master.

15. Les cycles de feedback sont les outils les plus importants pour les Scrum Masters ; définissez les et essayez de les rendre plus courts. Antti Tevanlinna rappelle que surtout le cycle de feedback qui implique le client est extrêmement important pour l'équipe. Nous, en tant que Scrum Master, devons comprendre le type de feedback dont l'équipe a besoin pour que le travail soit fait, et leur permettre d'obtenir ce feedback. Un cycle de feedback basique est la réunion de revue, où l'équipe montre la fonctionnalité qu'elle a réalisée, et la façon dont elle travaille. Un Scrum Master performant s'assurera que ce cycle de feedback est suffisamment rapide (1 à 2 semaines est un bon cycle), et efficace. Préparer des manières spécifiques de collecter et traiter le feedback assurera que le feedback est reçu avec une ouverture d'esprit, au lieu d'être vu comme hostile (lorsqu'il est négatif), ou hors propos. Rappelez-vous, le feedback est toujours de valeur. Mais à la fin, c'est l'équipe qui choisit comment elle y réagit.

Conclusion

Lorsqu'une équipe "s'approprie" finalement le processus, il peut apparaître que le travail du Scrum Master est terminé, mais il ne l'est jamais vraiment. Une fois que l'équipe "s'approprie" le processus, nous avons besoin de dévier notre focus sur les dynamiques d'équipe, aux impédimentas organisationnels, à l'interaction avec les parties prenantes, etc. Ce que j'ai appris de l'interview de 30 personnes sur le podcast de la Boite à outils du Scrum Master, est que la définition du succès pour un Scrum Master est très large. Différentes personnes vont se focaliser sur différents aspects de cette définition. Pas seulement cela, mais comme l'équipe et l'organisation changent, nous devons aussi nous focaliser sur différents aspects de cette définition. Cependant, il y a une tendance globale dans les réponses que nous avons collectées dans les derniers 6 mois d'interviews. Nous voyons deux définitions majeures du succès pour un Scrum Master : aider l'équipe à réussir en tant qu'équipe, et aider l'organisation à réussir en tant que business.

Les deux côtés de cette définition de la réussite sont valables et cruciaux pour nous afin de comprendre pleinement notre rôle en tant que Scrum Master. Nous devons constamment évaluer notre travail au regard de ces deux dimensions, et aider l'équipe et les parties prenantes à les comprendre. Assurez-vous que vous les considérez toutes les deux lors de l'élaboration de votre propre définition du succès.

A propos de l'Auteur

Vasco Duarte veut transformer les organisations de développement de produit en organisations de business de produit. Il fait cela en focalisant le travail des équipes de développement de produit sur le cycle de vie de bout-en-bout de leurs produits. Vasco est actuellement Gérant associé chez Oikosofy. Product Manager, Scrum Master, Project Manager, Directeur, Coach Agile sont seulement certains des rôles qu'il a pris dans les organisations de développement logiciel. Vasco travaille dans l'industrie logicielle depuis 1997, et est praticien Agile depuis 2004. Il a travaillé dans de petites, moyennes et grandes organisations logicielles en tant que Coach Agile et Leader dans l'adoption Agile dans ces organisations. Il était l'un des leaders et catalyseurs de l'adoption des méthodes Agile et de la culture Agile chez Avira, Nokia et F-Secure.