Après plus de 5 ans de pratique des démarches agiles et lean, ma pratique du rôle de scrummaster a largement évoluée pour s'éloigner de sa définition initiale.
A une phase tournante de mon engagement sur mon projet actuel, j'en profite pour faire un point sur le rôle initial de scrummaster et ce qu'il est devenu après plus d'une vingtaine d'itérations mensuelles. Cette évolution me semble si significative que le rôle strict de scrummaster me parait désormais sous-optimal.
SCRUMMASTER
Selon les fondateurs de Scrum, le scrummaster se doit de
- retirer les obstacles qui gênent l'équipe dans sa poursuite des objectifs d'itération;
- agir comme un tampon entre l'équipe et les influences perturbatrices;
- se mobiliser pour que la démarche Scrum soit mise en pratique conformément à sa définition;
- garder l'équipe concentrée sur les objectifs d'itération et les tâches en cours;
GESTIONNAIRE
Le rôle de scrummaster est bien loin du gestionnaire d'équipe (alias manager) qui pratique souvent un pilotage solitaire et analytique sur la base de métriques et d'indicateurs. Le manager gère des ressources sans forcement avoir recours à la pratique du leadership.
MENEUR
Le rôle de scrummaster s'apparente d'avantage à celui du meneur d'équipe (alias leader) même s'il n'en prend pas toute la force. En effet, le scrummaster est souvent présenté comme un facilitateur ou un animateur recherchant à tout prix le consensus au sein du projet. Ce rôle mou et peu engagé à mon avis n'est pas encore celui du meneur d'équipe.
Le meneur d'équipe mène son équipe (pléonasme).
S'ENGAGER
Mener son équipe c'est s'engager avec elle dans la poursuite de ses objectifs. Que cela soit bien clair: le leader échoue si l'équipe échoue. Le leader est bien dans la même barque que ses équipiers. Le leader doit donc contribuer à la poursuite des objectifs de son équipe. Il doit mettre ses compétences et son action au service de la réussite des équipiers.
Quelles sont ces compétences et cette action?
MONTRER L'EXEMPLE
Le meneur d'équipe doit montrer l'exemple. Il ne s'agit pas de dire ce qu'il faut faire, mais de montrer ce qu'il faut faire. Pour cela, il faut faire! On y revient encore: le leader est dans l'action. Il doit pratiquer pour montrer la voie à suivre. (Que penser du scrummaster facilitateur et non développeur?)
PRATIQUER
Un leader ne peut exiger de ses équipiers un comportement que lui-même n'a pas. Si le leader exige de ses équipiers que leur code soit testé, sans duplication, explicite et le plus court possible, alors lui-même se doit d'écrire du code testé, sans duplication, explicite et le plus court possible (j'en imagine certains qui sourient et d'autres qui grincent des dents). C'est à ce prix que le leader sera légitime et que ses équipiers accepteront de mettre en pratique les standards.
Ainsi, mener l'équipe c'est ouvrir la voie pour que l'équipe la prenne à sa suite.
ENSEIGNER
Il ne suffit pas au leader de pratiquer pour montrer la voie, puis d'exiger de ses équipiers qu'ils suivent cette voie. Le leader doit absolument enseigner le métier. Il doit enseigner
- la pratique en expliquant comment nous travaillons dans l'équipe (quels sont les standards?).
- la philosophie en expliquant pourquoi nous travaillons de cette manière dans l'équipe. L'enseignement de la philosophie est primordial car nous pratiquons de manière d'autant plus efficace que nous comprenons pourquoi nous pratiquons ainsi. L'objectif est de faire adhérer aux pratiques. Aussi (et surtout!), comprendre pourquoi est un pré-requis pour améliorer les pratiques.
Le pair-programming est une manière très pertinente d'organiser l'enseignement. Dans un tel cadre, le leader doit binômer et il doit s'assurer que les anciens binôment.
Petit rappel pour le plaisir: Pour enseigner il faut pratiquer.
FAIRE REUSSIR
L'objectif du meneur est de faire réussir ses équipiers. Une manière d'y parvenir est de mener les équipiers à l'autonomie, de les pousser à se perfectionner et à donner du sens à leur travail.
MENER A L'AUTONOMIE
L'autonomie a un impact positif sur la motivation, l'efficacité et l'engagement. Le leader se doit de pousser les équipiers à devenir autonomes.
Par exemple, il s'agit de ne pas de donner la solution à un problème posé, mais de mettre sur la voie, d'accorder du temps pour traiter le problème, puis de s'assurer que le problème est en cours de résolution.
Le meneur d'équipe doit pousser ses équipiers à le remplacer. Ainsi, les plus anciens participent à former les plus jeunes; chacun pilote un chantier de résolution de problème (et donc d'amélioration!); les daily-stand-up-meetings, planifications et rétrospectives peuvent être préparés et animés de manière tournante, etc.
Il est important d'organiser le travail pour que les équipiers puissent décider par eux-même de leurs activités. Les backlogs (priorisés par définition!), les faits techniques priorisés, les kanbans et taskboards, les standards et modes opératoires, les indicateurs visuels de pilotage, les andons sont des outils d'aide à la décision dont la bonne utilisation engendre l'autonomie.
En matière d'autonomie, les objectifs du leader peuvent être les suivants:
- s'il s'absente, l'équipe assure l'intérim;
- s'il quitte l'équipe, un équipier peut prendre son rôle;
- les équipiers identifient les tâches à mener;
- un équipier motivé peut mener une autre équipe.
CONDUIRE LE PERFECTIONNEMENT
Le leader doit pousser ses équipiers à se perfectionner. Des équipiers performants résolvent les problèmes et établissent des standards efficaces qui permettent de bien développer de bons produits. Le perfectionnement est également une grande source de motivation personnelle.
La mise en situation, le pair-programming et la résolution de problèmes sont des outils efficaces pour aider les équipiers à se perfectionner. Le leader peut utiliser ces moyens pour entretenir un rythme de perfectionnement.
DONNER DU SENS
Le leader doit expliquer aux équipiers quels sont les bénéfices pour l'entreprise, pour les clients, pour leurs collègues et pour eux-mêmes de leur travail et de leur manière de travailler. La conscience des bénéfices de son travail impact positivement la motivation et l'engagement.
CONDUIRE LA RESOLUTION DES PROBLEMES
Le scrummaster doit retirer les obstacles qui gênent l'équipe dans la poursuite de ses objectifs. En résolvant lui-même ces problèmes, le scrummaster ne mène pas ses équipiers à l'autonomie et il ne conduit pas leur perfectionnement. Lui seul développera ses compétences.
C'est pourquoi le meneur d'équipe doit conduire la résolution des problèmes. Il s'agit
- d'enseigner une démarche structurée de résolution de problème;
- d'expliquer en quoi cette pratique développe les compétences des équipiers;
- d'expliquer en quoi cette pratique améliore la performance de l'entreprise; puis
- d'allouer les chantiers dans l'équipe (ou de s'assurer que les équipiers s'allouent des problèmes à résoudre); et
- d'animer ou suivre l'avancement des chantiers de résolution de problèmes.
Pour montrer l'exemple et pour développer ses propres compétences, le leader se doit de mener lui-même des chantiers de résolution de problèmes.
La pratique en continue de la résolution de problèmes est un outil très performant pour développer les compétences. En effet, elle exige des équipiers qu'ils comprennent en profondeur les problèmes (avec symptômes, impacts et causes racines) et qu'ils identifient et mettent en place des contremesures efficaces.
AMELIORER LES PRATIQUES
La pratique en continue de la résolution de problème est également un outil très performant pour améliorer les pratiques (ou standards) de l'entreprise. En effet, ces chantiers font évoluer les standards pour intégrer les contremesures identifées.
Donc, là encore, le leader doit conduire la résolution de problèmes. Il doit tout particulièrement s'assurer que les équipiers enrichissent les standards avec les enseignements de leur chantiers.
RECHERCHER LE CONSENSUS
Bien sur, le meneur d'équipe doit en priorité rechercher le consensus au sein de l'équipe. L'adhésion aux décisions sera d'autant plus aisée.
Par contre, par moment, le consensus ne sera pas obtenu et c'est normal. Si je finançais mon projet avec mon argent propre, je ne laisserai pas les experts et les anciens ramer pour obtenir un consensus alors que leur expérience leur révèle la solution. Le prix d'un expert et d'un ancien est le prix de son expérience. Il se doit d'utiliser son expérience pour empêcher les plus novices de commettre les mêmes erreurs. Certes, nous apprenons par nos erreurs, mais si nous pouvions éviter d'en faire trop, ce serait tout même préférable pour le projet. Dans un tel cas de figure, une solution issue de l'expérience et imposée sans consensus doit être expliquée afin de rechercher au mieux l'adhésion des équipiers.
ET RECURSIVEMENT
Tout ce qui a été dit pour le meneur d'équipe me semble également valable pour le meneur de l'équipe des meneurs d'équipes. Et ainsi de suite ...
A méditer!
C'est beau des meneurs comme ça...
RépondreSupprimerVoilà un article que j'aurais bien aimé écrire !
RépondreSupprimerMerci ManU, je peux maintenant l'enlever de ma TODO-list !
(et bravo pour BustaFlex, fallait oser ;oD )
Je me retrouve parfaitement dans ta méditation, merci pour ton article !
RépondreSupprimerOui !
RépondreSupprimerLa question que je me pose est : peut on imaginer une équipe avec un role de scrum master et un rôle de leader incarné par deux personnes différentes.
RépondreSupprimer@Etienne: J'imagine que l'on pourrait en effet imaginer une telle équipe, même si je pense qu'elle souffrira d'un manque de clarté dans la répartition de rôles.
RépondreSupprimerEn effet, je crains qu'il n'y ait trop de recouvrements entre rôles pour que l'organisation soit évidemment la bonne.
Et là, je pense que l'on peut s'appuyer sur la similitude entre une équipe et son logiciel: si l'organisation/l'architecture et la répartition des rôles/responsabilités n'est pas simple alors l'équipe/le produit n'est pas efficace et viable à long terme. En organisation comme en architecture, je pense qu'il est primordial de rester clair et simple.
@Etienne @Manu
RépondreSupprimerJ'avais envie de poser la même question qu'Etienne.
Ce point de vue du meneur ne se heurte-il pas à la quête du Graal ?
J'ai bien peur que dans bien des contextes, on ne soit obligé de composer avec deux rôles, un scm et un "dev leader" (si possible tournant) si ce dernier n'a pas les qualités requises pour tous les aspects "gestion de l'humain" dans l'équipe
Alors effectivement, dans ce cas, les deux ont intérêt a très bien s'entendre pour éviter tout manque de clareté
Mais pour moi le deal est là : trouver l'équilibre entre un montage dual qui risque de manquer de clareté et la recherche du meneur omnicompétent qui risque de ne pas aboutir du tout
Belle définition.
RépondreSupprimerMerci pour ce blog et tous ces billets de qualité
@Emmanuel @David,
RépondreSupprimerEn fait, cela fait plusieurs projets (3 ou 6 mois pour chaque projet) que je fais dans ce mode : un scrum master différent du tech lead (qu'on appelle aussi parfois architecte, mais il s'agit bien d'une personne qui fait partie de l'équipe et qui développe la solution avec les autres).
Pardon d'avoir posé ma remarque sous la forme d'une question naïve. Je le regrette maintenant.
Pour décrire le contexte : Il s'agit d'applis web en java. Je suis un développeur expérimenté, mais le dev web est récent pour moi. J'interviens à la fois comme scrum master et comme dev sur les projets. Je suis toujours accompagné d'un tech lead (plus de 10 ans d'expérience et une solide expérience du dev web, mais une connaissance superficielle des méthodes agiles).
La plupart des projets se sont plutôt (très) bien passé mais j'ai connu une mauvaise expérience. Le tech lead n'était pas convaincu par l'approche incrémentale du développement (Il y avait plusieurs problèmes sur ce projet, mais c'est certainement cette difficulté qui m'a le plus contrarié et que je n'ai pas réussi à résoudre d’ailleurs).
Je ne doute pas que cela fonctionne bien quand le scrummaster/tech lead/mentor/coach de l'équipe se trouvent dans la même personne, mais je n'irai pas jusqu'à dire que le scrummaster devrait endosser tous ces rôles. Simplement parce que les personnes qui en sont capables sont trop rares.
RépondreSupprimerC'est là pour moi l'une des forces de l'agilité - n'importe qui peut prendre un rôle qu'il estime manquer à l'équipe.
Par contre je te rejoins dans l'idée qu'un scrummaster encourageant des méthodes XP sans tech lead/senior motivé ne peut pas fonctionner. Si l'équipe est plutôt réticente il faut quelqu'un pour montrer. Au moins.
@Etienne,
RépondreSupprimerje comprends que cette répartition des rôles puisse marcher. Après tout, il faut composer avec les ressources et profils disponibles pour organiser le succès.
En fait, ma réflexion ne porte pas sur la séparation des rôles entre scrum master & tech lead. Plutôt, je regrette que l'on dissocie scrummaster & leader d'équipe. Il se trouve de plus que pour être leader d'une équipe de développement, il faut pouvoir développer et enseigner le développement.
il semble "assez" naturel que le tec-leader diffuse son expertise, évangélise sur le TDD... et endosse de fait le rôle de scrum-master. En revanche, chez nous, ca laisse de la place pour un "chef de projet" qui "gère" les personnes, les plannings, les relations avec les clients, avec la hierarchie... Est-ce qu'un tel chef de projet a vraiment le profil du scrum-master ?
RépondreSupprimerBonjour,
RépondreSupprimerJe profite de ce billet sur les méthodes agiles pour diffuser ici un questionnaire y étant relatif.
En effet, je rédige actuellement un mémoire de recherche sur la gestion du temps selon le framework agile.En cela, je recherche donc des avis divers sur le sujet. Même si ma démarche n’est que peu courante, pourriez vous prendre le temps de répondre aux quelques questions le composant. En bien vous remerciant par avance pour les 5 minutes et de l’intérêt accordé. Cordialement, Jenna C.
https://docs.google.com/spreadsheet/viewform?formkey=dHdxR3JGX044a2gwMjRpVzJFZ3NLT3c6MQ#gid=0
I also took my PMP Classes from PMstudy. You can have a look at their offerings.
RépondreSupprimer