La malheureuse histoire du second Scrum Master
Je voudrais éclaircir un point concernant le rôle du Scrum Master. Parfois on m’a demandé mon avis sur des SM qualifiés de “mauvais”, d’autres de “bons”, et j’ai découvert un effet récurrent qui nous pousse à mettre trop d’exigence derrière ce rôle.
La malheureuse histoire du second Scrum Master
Dans les équipes qui démarrent en agile, le choix du Scrum Master se porte souvent vers la personne qui a le plus d’influence sociale. Ses coéquipiers sont habitués à le voir dépanner des problèmes, les gens l’appellent souvent à l’aide ; son nom vient comme un choix naturel lorsqu’il s’agit de trouver un M. Résoud-les-problèmes. Dans notre cas, appelons-le Jean.
L’équipe se repose sur lui pour la plupart des interactions avec le reste de l’entreprise (les autres équipes de dev, l’exploitation, voire le reporting aux instances supérieures). Jean serait le “bon Scrum Master”.
Puis vient un nouveau projet, une nouvelle équipe, un nouveau Scrum Master, appelons-le Kevin. A son tour, on le charge d’assurer les interactions externes, avec pour instructions : “le Scrum Master assure la communication de l’équipe“, voire même “il protège l’équipe des interactions extérieures“. Seulement le jeune homme est moins influent que son prédécesseur, il n’a pas les réseaux, moins de légitimité, et moins de talent relationnel. Au départ il est un peu dérouté. Puis débordé. Tout passe par lui mais Kevin n’a pas le temps ; parfois, il se montre maladroit. Il devient un frein à la communication extérieure. On le compare. On commence à le désigner comme un “mauvais Scrum Master”.
Le talent ne peut être une règle
Polariser les relations entre l’équipe et son environnement sur une seule personne en fait presque toujours un goulet d’étranglement… Sauf pour quelqu’un de très talentueux sur le relationnel, comme Jean.
Ce talent, c’est un coup de chance. On ne peut construire une pratique standard dessus, applicable par toute équipe. La définition en agile du rôle de Scrum Master est plus simple : c’est un facilitateur, il est responsable de l’amélioration continue de l’équipe. Chacun le décline à sa manière, apporte sa touche personnelle, et compose avec ses autres rôles (développeur, chef de projet, business analyst, etc.). Jean utilisait beaucoup la communication, Kevin fera autre chose.
Je ne sais pas si Kevin est bon ou mauvais, mais je pense que si on lui lâche un peu la grappe avec son prédécesseur, il pourra sûrement exprimer ses propres talents.
Mon nouveau blog pro : Agile après l'Ecole
J'aimerai y partager les finesses des méthodes de développement logiciel Agile/Lean, celles qu'on ne voit pas à l'école, que je découvre à la pratique -d'où le titre.
Read more
Peut-on tout étiqueter “Agile” ?
L’autre jour, j’ai eu une réaction épidermique, sans savoir vraiment pourquoi, alors que je discutais avec Jean-Claude Grosjean, mon binôme en mission, de son article sur le management agile. J’ai eu besoin de tirer mes idées au clair, voici ce qui en est sorti.
Quel est mon objectif ? Utiliser des termes précis pour décrire mon domaine (le développement logiciel) afin de l’enseigner et échanger avec mes pairs. Créer
et partager un cadre de pensée, basé sur des concepts finis. On ne peut pas coller l’étiquette “agile” sur tout ce qu’on touche.
Au travers du développement agile nous découvrons de nombreux sujets connexes : complexité des organisations, facilitation des échanges, dynamique d’équipe, etc. Nous les associons au thème de départ, mais je pense que c’est un abus. Ces concepts sont connexes à notre domaine, mais ils ne lui sont pas spécifiques.
Je pourrais parler de management agile dans des activités précises, comme la gestion de portefeuille de projets itératifs, par exemple. Pour moi, un manager au carrefour du leadership et de la gestion n’est pas spécifiquement “agile” : cette posture de management existait déjà hors de notre domaine.
A titre de comparaison, on ne fait pas d’amalgame sur la facilitation. Nous en utilisons quelques outils classiques (agenda, support visuel, divergence/convergence, etc), et pourtant je n’ai jamais entendu qu’on faisait de la facilitation “agile”. On en utilise, c’est tout.
Poussons le bouchon : les post-its sont-ils agiles ? Tant qu’ils restent de simples bouts de papier adhésifs que votre mère collait sur le frigo, non. Mais quand ils seront pré-imprimés, par exemple en cartes de user stories spécialement conçues pour Scrum, oui, on pourra parler de post-its agiles.
Alors, pourquoi ça m’a piqué ?
En fait, je crains qu’on manipule l’Agile comme une marque, qu’on repositionne pour attaquer de nouveaux segments de marché. J’ai peur d’être décrédibilisé, comme si je fourguais mon produit, alors que je fais juste les recommandations qui me semblent pertinentes dans le contexte.
Je ne vends pas l’Agile, je vends mes conseils, je ne veux pas qu’on se méprenne.
…
Bon, en réalité ça me pique pas tant que ça. Je survis très bien aux contradicteurs qui m’envoient “tu vends ta sauce”, ils me donnent l’occasion d’expliquer ma démarche.
Finalement, c’est peut-être mon côté obtus : pour moi c’est important d’utiliser des termes spécifiques pour des concepts définis, ça me parait une condition nécessaire à la progression de toute science. Sinon… “ça m’énnnneeeeeeeerve” (air connu).
La vraie nouveauté de la keynote Apple WWDC 2013
J’avais commencé à regarder les keynotes Apple pour analyser les techniques de présentation de Steve Jobs. Puis j’ai continué quand la pomme a commencé à s’emballer, en dévoilant année après année le macbook air, l’iphone, l’ipad, juste par impatience technophile. Bref, c’est devenu une habitude, même si je me suis parfois ennuyé.
Maintenant Steve est mort, je crois que cette keynote (WWDC 2013) est la 3e ou 4e sans lui. J’ai lu qu’elle marque l’air post Jobs car elle montre enfin des innovations, des produits nouveaux : iOS7 à l’interface totalement revue, le futur Mac Pro tout cylindrique. Moi ce sont les présentateurs qui m’ont marqués.
Pour la première fois, les patrons, Schiller et compagnie, s’éclataient sur scène. Ils étaient enthousiastes, ils se lâchaient, ils avaient l’air vraiment fiers de leurs nouveaux produits. Avant, on les sentait coincés, entrainés à imiter timidement le phrasé de leur leader : mots bien détachés, superlatifs à tout va. Mais au lieu de l’air passionné de feu leur boss, ils avaient l’air de répéter leur texte et de mal le jouer. Maintenant ils s’expriment, on sent qu’ils pensent ce qu’ils disent. Et ils ont l’air d’avoir le feu ! (… ok, sauf Tim Cook qui continue à imiter)
En analyse systémique, on dit “le produit reflète l’équipe”. Il vient de là mon espoir suite à cette Keynote : la nouvelle team de direction Apple vient de prendre son envol, donc les produits ne devraient pas tarder à suivre.
Rallonger ou pas les itérations
La question est super classique : “on arrive pas à terminer tout ce qu’on a commencé, on pourrait pas rallonger les sprints ?”
C’est un piège. Si vous n’arrivez pas à terminer ce que vous avez commencé, 2 solutions s’offrent à vous : rallonger les sprints, ou faire moins de choses à la fois.
La seconde option est ma préférée, celle qui est recommandée : l’équipe commence une histoire, deux à la rigueur, et on en commence pas d’autre avant d’avoir terminé.
Problème souvent observé : les histoires sont trop grosses pour être terminées en un seul sprint. Donc pour en faire moins à la fois, il faut découper les histoires, diviser les fonctionnalités jusqu’à avoir un rythme de travail fluide, et peu d’encours.
Pourquoi l’allongement des sprints n’a pas ma préférence ? En fait, on risque de doubler le problème : 2 fois plus de planification nécessaire, risque d’avoir 2 fois plus d’encours, et 2 fois moins de rétrospectives pour s’en rendre compte.
Confiance et contrôle, application aux jeux de rôles
Je relatais ailleurs comment, paradoxalement, une équipe avait amené plus contrôle sur son travail en se faisant confiance.
Ca me fait penser à une pratique que nous avons instauré autour de notre table de jeux de rôles pour vérifier que personne ne triche au dés.
Je ne sais plus si j’ai déjà parlé des tricheurs dans les communautés de joueurs, mais ce n’est pas un phénomène rare. Et c’est parfois une plaie. Ils ne l’avoueront jamais pour eux-mêmes, et comme ce sont des amis, les confronter pourrait créer une crise. Donc on a cet espèce de consensus : personne ne triche, mais on contrôle les jets de dés.
Traditionnellement, la tâche de contrôle incombe au maître de jeu : “tu jettes tes dés quand je regarde”. Mais le MJ, pendant la partie, il est généralement débordé, alors les joueurs l’attendent, souvent. Et d’ailleurs, pourquoi ce serait seulement à lui de contrôler ? Tous les joueurs sont embêtés lorsqu’un joueur triche au dés ! Il déséquilibre la partie, s’accapare les réussites, c’est chiant pour tout le monde. Si vous avez déjà essayé de jouer avec un gars qui “réussit” 8 fois sur 10 des jets à 30% de chance, vous comprenez comme c’est pesant.
Chez nous, les joueurs sont chargés de se contrôler entre eux. La responsabilité partagée est posée : on ne triche pas, mais comme la tentation peut être grande, tout le monde contrôle tout le monde. Entre amis.
Quant au maître de jeu, il se focalise sur son rôle : animer un beau scénario.
Même conclusion que dans des articles précédents : on joue ensemble.
—-
Edit : lien vers l’article “Confiance et contrôle” sur Agile après l’école, mon blog sur l’agile