Série - ScrumMaster

Fil des billets - Fil des commentaires

Le rôle de ScrumMaster

Un résumé du rôle de ScrumMaster, l'animateur d'une équipe qui applique Scrum.

Synonymes

  • Coach agile.
  • Facilitateur de processus.
  • Scrum Master (en 2 mots)

On peut voir le ScrumMaster comme la déclinaison agile du chef de projet, mais cela ne favorise pas la compréhension du changement induit [1].

Analogies

  • Le terme Scrum vient du rugby. Le poste de demi de mêlée est celui qui se rapproche le plus de l'idée de ScrumMaster.
  • Ken Schwaber compare le ScrumMaster à un berger qui veille sur son troupeau.

Responsabilité

Il a pour responsabilité, dans le cadre du développement d'un produit, d'aider l'équipe à travailler de façon autonome et à s'améliorer constamment. Il est le garant de l'application du processus, Scrum en l'occurrence.

Travaux du ScrumMaster

Tâches périodiques

Mettre en application Scrum en organisant et animant les réunions qui constituent le cérémonial :

Tâches sur évènement

  • éliminer les obstacles : prendre en compte les problèmes qui surviennent à tout moment sur un projet pour les éliminer au plus vite, en évitant qu'ils ralentissent l'équipe. Il protège l’équipe des interférences extérieures.

Tâches de fond

  • faire en sorte que l’équipe reste concentrée sur le véritable objectif du projet, qui est de réaliser les éléments du Backlog en collaboration étroite avec le Product Owner, et soit productive. Il s'assure que chacun participe pleinement aux travaux de l'équipe.
  • communiquer avec le management. La transparence est de mise avec des rapports d'avancement comme les burndown charts ou mieux des burnups.

Compétences

Les compétences et l'expérience souhaitées dépendent de la taille, de la complexité technique et du type de gouvernance. Les qualités nécessaires pour jouer efficacement ce rôle :

  • bien connaitre Scrum,
  • avoir des facilités de présentation, de communication et de négociation,
  • guider sans imposer,
  • faire preuve de qualité de meneur d'hommes et savoir motiver une équipe,
  • savoir résoudre les conflits et les problèmes,
  • communiquer honnêtement sur le degré d'avancement,
  • garder le respect de l'objectif essentiel, qui est de livrer un produit qui apporte de la valeur.

Il n'est pas nécessaire pour un ScrumMaster de bien connaître le domaine de l'application, ni d'être un expert technique. Cependant une expérience de l'un ou l'autre rendra le rôle plus facile à tenir.

Affectation

Pour une équipe Scrum typique (de 6 à 10 personnes), une seule personne joue ce rôle sur un projet. Celui qui le joue peut, ponctuellement, participer aux travaux du sprint avec les autres membres de l'équipe, mais cela doit rester limité : c'est un rôle à plein temps, sauf pour des petites équipes.

Points clés

  • Ce n'est pas un chef de projet : il ne dirige pas, il n'impose pas, il ne contraint pas.
  • Il fait partie de l'équipe : il s'engage avec les autres.
  • Il doit régulièrement rencontrer -physiquement- les autres membres de l'équipe, il ne reste pas dans son bureau.

Note

[1] voir sur ce sujet le billet de l'Agilitateur

Compétences souhaitées d'un ScrumMaster

La personne idéale pour jouer le rôle de ScrumMaster devrait posséder les compétences suivantes :

  • bien connaître Scrum,
  • avoir des talents de communication,
  • être capable de guider sans imposer,
  • savoir résoudre les conflits,
  • avoir le courage de communiquer honnêtement sur l'avancement du projet,
  • savoir développer la force collective de l'équipe.

Avoir une culture technique est très souvent utile. En effet, cela permet au ScrumMaster de mieux communiquer avec les membres de l'équipe et cela facilite la résolution des problèmes (impondérables).

La certification Scrum encore plus discréditée

Ceux qui lisent ce blog ou suivent ce qui se passe autour de Scrum savent depuis longtemps que la (pseudo-)certification Scrum est controversée et la Scrum Alliance critiquée pour son opacité.

Un espoir de rénovation avait été entrevu quand Tobias Mayer, connu pour son attachement aux valeurs et son intégrité, avait rejoint le board il y a quelques mois comme Creative Director. Las, il annonce dans un billet récent "The Scrum compliance" qu'il rend son tablier et renonce à toutes ses certifications. Son jugement est très sévère :

The SA is the archetypical unScrum organization, a big lumbering machine, intent on maintaining its status quo, valuing profit over service, control over trust, and engaging in operating practices that are opaque, undemocratic and lacking in integrity.

En France, on peut ajouter comme inconvénients supplémentaires la distance et la différence culturelle.

L'Institut Agile a une position claire sur le sujet : défavorable à toute démarche de certification[1] ou de labelisation qui induirait des dérives ou des divisions.

On pourrait m'accuser de plaidoyer pro domo puisque je propose des formations Scrum. Je n'en ai pas besoin : mes formations marchent très bien en ce moment. Non, ceux que je veux défendre, ce sont les participants à ces formations.

Imaginons qu'ils soient en concurrence pour un emploi ou une participation à un projet avec d'autres qui auraient mis sur leur CV "scrumMaster certifié". Il serait très injuste que des recruteurs considèrent cela comme un avantage compétitif.

C'est donc à ces recruteurs que je m'adresse pour dire à ceux qui ne le savaient pas encore que, dans ce cas là, certifié signifie simplement avoir assisté (en principe) à une formation de 2 jours [2], peut-être en anglais.

Pour finir par un clin d'oeil : pour le CV, on peut suivre la proposition de Jlase dans les commentaires de mon livre chez Amazon :

je pense changer mon CV pour remplacer "SM Certifié" par "j'ai lu le livre SCRUM".

Notes

[1] à relire : UncleBob sur le gaspillage de temps que ça représente

[2] je ne dirai pas formation certifiante, j'ai toujours considéré que c'était une hérésie d'accoler ces 2 mots, en plus du fait que ce soit du mauvais français

ScrumMaster ou Scrum Master ?

Ou scrummaster ? voire scrumaster ?

La lecture du dernier article de Scott Ambler dans DrDobbs "Certified ScrumMaster Examined" m'a interpellé, non pas sur la certification[1], mais sur la façon d'écrire ScrumMaster.

ScrumMaster ou Scrummaster ou Scrum Master ?

Depuis le début de mon blog, j'écris ScrumMaster. Je me souviens m'être posé la question au tout début, il y a 5 ans. Finalement j'avais repris l'orthographe utilisée dans le livre de Ken Schwaber "Agile Project Management with Scrum", avec les 2 mots collés et le M en majuscule. Pareil dans mon livre.

Comme le dit Scott qui a analysé la genèse de la formulation, ScrumMaster est le terme de la Scrum Alliance.

Que disent les autres français ?

  • Un coup d'œil sur le site du French SUG montre que... les 2 sont utilisés dans la même page.
  • Cyrille, dans Le Bouzin Agile emploie le vocable Scrum Master, comme Alex.
  • Fabrice, Thierry[2] et JC sont adeptes de ScrumMaster.

Je suis allé voir dans Google Analytics, pour savoir quelle appellation utilisaient ceux qui recherchaient des informations sur ce rôle sur Google et arrivaient sur mon site.

Voilà ce que ça donne, avec l'évolution au fil des ans.

Pour ScrumMaster (ou scrummaster, il n'y a pas de distinction minuscule majuscule dans les mots clés) :

  • 96 en 2007,
  • 289 en 2008,
  • 391 en 2009,
  • 470 en 2010

Pour Scrum Master :

  • 20 en 2007,
  • 522 en 2008,
  • 1254 en 2009,
  • 2032 en 2010

Sans contexte, c'est Scrum Master qui est le plus utilisé, et la tendance s'amplifie.

En étudiant les statistiques sur les mots clés de recherche, j'ai aussi vu des scrumMasters ou scrum masters associés à certification, mais j'ai constaté avec plaisir que leur nombre avait diminué en 2010 par rapport à 2009 (environ 400 recherches).

Quant au Product Owner, il reste bien en deçà du ScrumMaster :

  • 198 en 2009
  • 403 en 2010 (plus 45 scrum product owner plus environ 150 directeurs de produit, mais pas de ProductOwner).

Alors finalement, maintenant dans mon blog et pour la deuxième édition de mon livre, je me demande si je ne vais pas passer à Scrum Master.

Notes

[1] que Scott combat avec acharnement et je ne vais pas en rajouter

[2] oui, même Thierry utilise le vocabulaire de Scrum !

Quizz, la question 3 sur le ScrumMaster

La question était la suivante :

Une personne dans l’équipe perturbe les autres. Vous êtes ScrumMaster, comment réagissez-vous ?

Vous aviez le choix entre les réponses suivantes :

  1. Vous la virez de l'équipe, la majorité est d’accord
  2. Vous ne faites rien, il n’y a pas de chef avec Scrum
  3. Vous faites un rapport à la direction
  4. Vous l’invitez à prendre une bière pour lui proposer d’être le ScrumMaster du prochain sprint

Rappel : il s'agit de la 3ème question, sur les 15 qui sont proposées à la fin de l'édition 2 de mon livre et qui sont un extrait des 70 qui font l'objet d'un QCM suivi d'un débat mené le dernier après-midi de mes formations Scrum.

Cette fois, une large majorité parmi les 113 votants s'est dégagée sur la réponse que j'aurai aussi choisie. L

On pouvait procéder par élimination.

Ne rien faire

En fait cela dépend un peu de l'intensité et de la fréquence de la perturbation. Comme cela n'était pas précisé, on pouvait supposer que cela considérait un véritable obstacle. Or si le ScrumMaster n'est effectivement pas un chef, il a comme mission d'éliminer les obstacles qui bloquent ou simplement freinent l'équipe. Ne rien faire, comme l'ont proposé 6,19%, n'est pas dans l'esprit du rôle.

Rapport à la direction

Puisque le ScrumMaster doit faire quelque chose, pourquoi pas un rapport à la direction se sont dit 6,19% des participants au quizz. Mais le ScrumMaster doit d'abord chercher une solution avec l'équipe. Une de ses responsabilités est de l'amener vers plus d'auto-organisation et je doute qu'un rapport à la direction y contribue.

Le virer

Le ScrumMaster n'est pas un chef et l'équipe est autonome, alors comme 15,93% des votants, on pourrait se dire que l'équipe peut décider à la majorité. Mmmmh, avec ce genre de pratique d'exclusion, je pense qu'on est loin des valeurs préconisées. Le ScrumMaster est là pour aider à résoudre les conflits, qui ne manquent pas d'arriver dans les équipes. Il peut même essayer de les anticiper. Si le conflit est avéré, il doit mettre en place les discussions permettant d'en trouver les raisons profondes.

Réponse 4

Pendant longtemps, la réponse 4 de cette question était : le ScrumMaster tente de résoudre le conflit. Comme je trouvais que c'était un peu facile, j'ai changé le texte pour instiller un peu plus de doute. Cela n'a pas empêché 71.68 % de la choisir. La bière est un bon moyen d'établir le climat permettant de remonter aux causes profondes du problème. Lui proposer de devenir ScrumMaster est une façon subtile, mais qui peut être risquée s'il accepte, de responsabiliser le perturbateur. Une approche plus classique que la bière est la discussion franche avec toute l'équipe, lors de la rétrospective par exemple. Mais ce n'était pas parmi les réponses proposées.

Dans un billet récent, Emmanuel Chenu revient sur ses années d'expérience dans ce rôle, qu'il préfère maintenant appeler meneur d'équipe. Meneur, ça se discute, mais ça montre au moins que ce n'est pas un rôle passif.

Scrum n'est pas hordesque

J'avais dans l'idée de faire un billet sur un des nombreux jeux de cet excellent Agile Games France, mais le billet tripal de Pablo sur la horde a changé mes priorités.

J'avais récemment évoqué la horde dans un de mes billets, l'épisode 5 de ma série sur mon histoire de Rupture douce. Un épisode où il aussi est question de pouvoir latéral, de Skull & Roses et de ...Pablo.

Dans mon billet la horde était l'archétype du groupe avec un chef choisi pour sa force ou son courage. Pablo se réfère à la horde comme exemple du comportement d'équipes ou de communautés agiles. Je trouve l'idée très intéressante. L'analogie me paraît plus adaptée que celle du troupeau, qui n'est finalement qu'une horde apprivoisée (et donc soumise).

Je crois me souvenir que, dans un livre ou un article que j'ai lu il y a plusieurs années, Ken Schwaber présente le ScrumMaster comme un shepherd, reprenant l'analogie pastorale du berger[1].

Je viens de lire un ouvrage ardu mais très intéressant de Jean-Claude Monod Qu'est ce qu'un chef en démocratie [2]? J'y ai appris que Freud réfutait la qualification de l'homme comme bête de troupeau pour le présenter comme bête de horde[3].

Freud définit l'homme comme membre individuel d'une horde conduite par un chef suprême. Il écarte l'idée de passivité du troupeau, le membre d'une horde pouvant renverser voire tuer le chef pour prendre sa place.

Ça colle pas mal avec ce que présente Pablo dans sa tripologie hordesque sur le leadership naturel.

Ça ne colle pas du tout avec Scrum (dont Pablo ne parle pas).

Pas parce qu'une équipe Scrum serait un troupeau plutôt qu'une horde : elle n'est pas passive.

Mais parce que la notion de leader dans Scrum est traitée de façon bien différente.

Les responsabilités qu'on attribue à un chef dans l'histoire sont largement partagées : prévoir, anticiper[4] et entraîner le groupe.

Ce qui fait la grande particularité de Scrum, en tout cas parmi les pratiques de management, c'est que ces responsabilités traditionnelles du chef ne sont pas confiées à une seule personne, mais partagées entre deux : le Product Owner prévoit et anticipe, le ScrumMaster entraîne les membres de l'équipe vers ce que demande le PO (et il est bien clair qu'il n'est pas le chef). C'est ça qui fait l'originalité et la force de Scrum, cette tension entre le PO qui demande et l'équipe qui réalise, tension contrôlée par le SM. Sans parler d'auto-organisation de l'équipe, il n'y a pas un seul chef comme dans la horde.

Une équipe Scrum n'est pas donc une horde primitive, au moins sur le plan du leadership.

Notes

[1] j'en avais parlé dans mon billet sur le ScrumMaster de 2007

[2] Sous-titre Politiques du charisme, publié dans l'Ordre philosophique au Seuil.

[3] En allemand, une seule lettre change de Herdentrier à Hordentrier, page 241 du livre.

[4] Monod parle de la faculté à deviner le coup d'après.

Retour sur ma formation ScrumMaster

La semaine dernière, j'ai donné une formation de deux jours, pour des ScrumMasters qui pratiquaient déjà.

A mes débuts de formateur Scrum (ça commence à faire longtemps), j'avais 3 formations, une pour les PO, une pour les SM et la dernière pour les développeurs. Puis finalement j'ai fait très majoritairement des formations Scrum pour toute l'équipe. C'était bien mieux comme ça. Quand une équipe démarre, il faut former tout le monde.

Maintenant que Scrum est largement utilisé, il me semble pertinent de proposer des formations approfondies pour ceux des PO et SM qui pratiquent déjà depuis quelque temps et veulent aller plus loin.

C'était ma première formation depuis que j'ai écrit l'édition 3 de mon livre Scrum. J'y ai incorporé de nombreuses nouveautés qu'on retrouvera dans la publication de juin.

Côté ateliers et jeux, des nouveautés aussi dans cette formation ScrumMaster. Parmi celles-ci, ces trois ont beaucoup plu :

  • Suite à ma participation à Agile Games d'Avignon en février, j'ai incorporé le Delegation Poker.
  • Nous avons fait Au Tableau (photo).
  • Un quiz spécial ScrumMaster.

Atelier Au Tableau

Le nouveau livre de Véronique Messager "Coacher une équipe agile" a été fourni aux participants, en plus du mien. Je l'avais lu avant la formation, il apporte de nombreux outils au ScrumMaster qui veut faire progresser son équipe vers plus d'auto-organisation.

Une après-midi révélatrice de ScrumMaster

Dans l'édition 4 de mon livre, j'ai ajouté des histoires pour raconter une journée typique d'un ScrumMaster et d'un Product Owner.

Voici la deuxième partie avec un extrait tiré du chapitre 5 Le rôle du ScrumMaster.

Nous avions laissé Nicolas, qui tient ce rôle dans l'équipe Peetic (le site de rencontres pour animaux de compagnie), au bord du canal, pour une séance de jogging, après une belle matinée de ScrumMaster.


Le temps de prendre la douche et la pâtée, c’est l’heure de la réunion d’affinage[1]. On y a invité Laurent, l’expert en cartographie, car il y a des stories à affiner sur ce sujet . Mais Laurent a dû oublier, il n’est pas là ! Nicolas l’appelle et apprend qu’il a une urgence. Il négocie sa venue pour un quart d’heure. On change un peu l’ordre des activités de la réunion pour saisir le créneau, c’est important qu’il soit là. Finalement, l’affinage se passe bien, il y a suffisamment de stories prêtes, Nicolas en compte 10.

Après la réunion, il reste avec Céline le PO[2] pour mettre à jour le plan de release, qui a été pas mal touché par le travail d’affinage. Mais il est appelé par Sébastien qui lui annonce que le serveur de développement est en rade. Il laisse Céline finir et file voir Sébastien. Bon, pas trop grave, il suffisait de relancer le serveur.

Il a un peu de temps avant sa réunion pour analyser les raisons profondes du gros bug de la semaine dernière, alors il passe voir l’essaim[3] qui s’occupe de la story « Modérer les photos de chien ». Il aide en passant deux vérifications de sa définition de fini[4]. La story va être finie ce soir !

Il anime la discussion sur le gros bug, en proposant les 5 pourquoi pour remonter à l’origine du problème. Mmm, il semble qu’il faudrait ajouter une règle de codage.

Lors de la mêlée du matin, il a deviné qu’Émilie avait des soucis. Il va la voir, avant qu’elle parte. OK, il arrive à comprendre qu’elle est en conflit avec David, il ira lui parler demain. Faudra qu’il pense à proposer un niko-niko[5] à la prochaine rétrospective pour, peut-être, anticiper ce genre de situation.

Avant de partir, il consulte ses messages et voit une demande de Kevin qui voudrait emmener Julien, dès demain et pendant 2 jours faire des démos chez des clients. Après une discussion franche, il dit non, cela remettrait en cause l’objectif du sprint.


Notes

[1] L'affinage du backlog fait l'objet du chapitre 7

[2] Le rôle de Product Owner est décrit dans le chapitre 4

[3] le groupe de développeurs qui butine sur une story

[4] La définition de fini fait l'objet du chapitre 8

[5] anonyme, avec Teammood