Scrum Master Fluency : faire évoluer le rôle au rythme de l’équipe

Trouver sa place dans l’équipe quand on prend son rôle de Scrum Master est un défi et pour plusieurs raisons.

L’une d’entre elles est liée à ce que nous évoquions dans le précédent article : le rôle de Scrum Master “souffre” en entreprise de certaines incompréhensions. La non-clarification de ses responsabilités et de son impact entrainent un questionnement sur sa légitimité / sa plus-value.

Une autre raison est la difficulté de structurer son activité. Les multiples facettes d’un projet (organisation, technique, fonctionnel) engendrent une complexité multi-dimensionnelle que le Scrum Master doit visualiser. En effet, cela pourra l’aider à structurer sa démarche. Voyons ensemble comment il peut procéder.

Mon inspiration : le modèle Agile Fluency 

Le modèle Agile Fluency a été fondé par Diana Larsen and James Shore. Son intention est d’aider les équipes et organisations à définir leur cheminement, en prenant en compte les différents types de changement auxquels l’équipe va être confrontée (culturel, organisationnel).

Le modèle est résumé sur votre droite.

Nous ne rentrerons pas dans les détails dans cet article. Je vous invite à visiter le site, qui explique très bien les concepts abordés dans le modèle.

Ce qui va nous intéresser ici va être d’imaginer un parallèle entre ce modèle et la démarche du Scrum Master. Comment notre Scrum Master peut-il s’emparer de ce modèle pour structurer son propre accompagnement ? Voici les 3 axes qui peuvent en ressortir :

Focus on team culture and organisation

Aujourd’hui, un Scrum Master arrive dans une équipe qui implémente déjà un embryon de pratiques agiles. Après une période d’analyse du contexte, son attention va se focaliser sur cette partie culture :

• Quelle est la raison d’être de l’équipe au sein de l’organisation ?
• Quels sont ses objectifs à court et à long terme ?
  On va parler vision :
  • Business (comment est le marché autour de notre produit),
  • Produit (comment nous imaginons le futur de notre produit),
  • Technique (quelles sont les solutions techniques que nous allons devoir implémenter dans le futur, avec quels enjeux et quels risques)
• Quelle est notre routine d’équipe ?
  On va parler cérémonies et comment l’équipe met en place les boucles de feedback à différents niveaux
• Comment fonctionnons-nous ?
  On va parler de charte d’équipe ou de (re)travail les rôles avec une matrice Give And Take…
• Pourquoi met-on en place des pratiques agiles ? Lesquelles ? A quelle(s) fin(s) ?

Le cadre Scrum va donner des pistes pour répondre à certains de ces points. Cependant, l’enjeu pour le rôle de scrum master est majoritairement de faire émerger un cadre organisationnel correspondant à l’équipe, son historique, ses contraintes et ses enjeux.

Focus on team delivery

Le second aspect sur lequel se penchera notre Scrum Master est autour du delivery – la capacité de l’équipe à livrer régulièrement des éléments de valeur.

Ici, plusieurs aspects vont émerger :

• Améliorer le découpage du backlog : en accompagnant le Product Owner à la mise en place d’un système de valeur, en l’aidant à trouver le bon format dans l’expression de ses besoins… 
• Travailler autour de la préparation des réalisations (refinement), en s’assurant que les boucles de feedbacks avec les parties prenantes et l’équipe de réalisation sont en place, sont fluides et apportent les réponses nécessaires
• Affiner une vision stratégique et tactique avec l’équipe élargie (PO  + réalisation) pour initier, partager et challenger cette vision.
  Nos meilleurs alliés : l’Impact Mapping et le Story Mapping seront

Focus on team improvement

Difficile de s’améliorer sans pouvoir mesurer, comparer.

La difficulté souvent rencontrée est de trouver quels indicateurs utiliser, lesquels font du sens. Le premier qui vient à l’esprit est la vélocité. Et bien c’est l’indicateur que j’utiliserai en dernier !

1. Son partage en dehors de l’équipe ne devrait pas se produire.
2. Les parties prenantes le comprennent mal et devient l’unique référence de la “performance” de l’équipe
3. Une équipe qui a un tant soit peu travaillé ensemble sur quelques semaines n’a, selon moi, pas besoin de vélocité pour définir un périmètre d’itération ni réaliser de projection

Donc, notre Scrum Master va pouvoir travailler à la mise en place d’indicateurs permettant d’aider l’équipe à mesurer son “efficacité” et trouver des leviers d’amélioration. 
Ces indicateurs vont aider l’équipe à évaluer l’efficacité de son organisation, la qualité du travail réalisé, la réponse au besoin. Pour résumer ceci, j’aime bien rappeler cette image extraite de la vidéo d’Henrik Kniberg “Agile Product Ownership in a Nutshell”.

Ainsi, les indicateurs peuvent être :

• “techniques” (tests, performance, qualité de code, …), 
• “métiers” (utilisabilité des features, satisfaction utilisateur, change failure rate (nombre de déploiements en prod sans échec ..)
• “organisationnels” (Lead Time, Cycle Time, nombre de déploiements sur une période

Ces indicateurs restent très opérationnels. Or le succès de l’équipe passe également par d’autres aspects, bien plus centrés sur les êtres humains qui composent le groupe. Je vous renvoie vers un post très intéressant de Céline sur le sujet de la sécurité psychologique.

Charge au Scrum Master de déterminer avec l’équipe les plus pertinents !

Comment répartir le rôle du Scrum Master dans le temps

Le modèle Agile Fluency explique la nécessité du temps à passer pour la mise en place de chaque phase.

Dans notre modèle, l’expérience nous montre que les 2 premiers focus avancent en partie en parallèle. En effet, l’organisation de l’équipe est directement liée à sa manière d’organiser son delivery : l’un ne va pas sans l’autre.

Si on peut imaginer qu’en quelques semaines, la première phase est structurée et permet d’avoir un démarche définie sur laquelle nous allons pouvoir itérer, la seconde peut prendre un peu plus de temps. Et cette durée sera fonction par exemple de :

• La complexité plus ou moins importante liée à un legacy sur le backlog,
• La manière de découper le travail,
• Les habitudes autant chez un Product Owner que chez l’équipe de réalisation…

Enfin, la dernière phase est perpétuellement sous-entendue : l’amélioration continue n’a pas de limite.

Sans parler du fait que les départs, les arrivées, les changements d’organisation…rythment la vie des équipes. Et il est donc parfois nécessaire de retravailler l’organisation interne de l’équipe par exemple.

Ça fait beaucoup, non ?

Avec tout ceci, on peut avoir l’impression d’attendre beaucoup d’un Scrum Master. Oui, effectivement. Trop ? Je ne pense pas.

Les différents aspects évoqués entourant le delivery sont des pré-requis à l’efficacité globale. Et il est difficile d’imaginer un de ces aspects non abordés.

L’efficacité recherchée va être un vrai équilibre entre :

• Le fonctionnement de l’équipe en tant que collectif,
• Sa capacité à définir ce qu’il y a de mieux à faire pour elle et comment le faire,
• Ainsi que sa capacité de prise de recul sur l’ensemble de ses pratiques et réalisations, pour mieux performer dans le temps.

Ces éléments ne sont pas la propriété unique du rôle de Scrum Master. C’est la responsabilité collective de l’ensemble de l’équipe. Celle du Scrum Master sera d’aider à structurer et de sensibiliser.

Matthieu

J’évolue depuis près de 15 ans dans le développement applicatif.

D’abord développeur, j’ai pendant plusieurs années eu des activités de Scrum Master et de Coach Agile qui m’ont permis de naviguer dans des environnements variés et de collaborer avec les multiples acteurs des organisations.

Je suis maintenant revenu à mes premiers amours et propose mes services en tant que Développeur Back-end et Scrum Master.