Après quelques mois de partage de mon voyage en Systémique dans les Agile Tours ou ailleurs (voir ma présentation sur slideshare) et la création du groupe Meetup “Katas de représentations systémiques” pour s’entraîner à représenter des systèmes, je reprends ma suite de billets sur la systémique avec des exemples de représentations.
D’abord impuissant face à la complexité apparente, j’ai en effet commencé à utiliser les diagrammes systémiques proposés par Senge pour représenter les systèmes que j’accompagnais afin de mieux comprendre certains comportements observés.
Mais que faire concrètement de cet outil et de cette complexité apparente dans mes accompagnements ?
J’assiste à un Sprint Planning d’une équipe Scrum.
Lors de cette réunion, j’ai observé un Scrum Master très présent dès le départ, qui devenait de plus en plus présent au fur et à mesure que la réunion dérivait, en essayant de tenir la barque autant que possible, comme le font beaucoup de Scrum Masters dont l’objectif prioritaire est de tenir le cadre du meeting et remplir les objectifs tels que définis dans le Scrum Guide.
J’ai noté que plus il tenait le cadre plus ça partait en vrille, plus il tenait le cadre, plus ça partait en vrille, etc… Et j’y ai vu une belle boucle amplificatrice, chère à Peter Senge dans ses représentations, que je me suis amusé à représenter !
On y voit trois boucles amplificatrices en fait.
Plus le Scrum Master prend de place, plus l’équipe s’efface, moins elle s’auto-organise, plus le Scrum Master prend de place
Plus le Scrum Master prend de place, plus le Product Owner s’efface, moins de sens fonctionnel est donné au sprint, plus le Scrum Master prend de place
Plus le Scrum Master prend de place, plus le Product Owner s’efface, moins de sens fonctionnel est donné au sprint, moins l’équipe peut réellement s’engager, plus le SM prend de place”
A la lecture de cette représentation systémique, il me semble alors qu’en voulant bien faire, le Scrum Master ne règle pas le problème. Pire, il l’empire !
Le Product Owner n’est pas assez impliqué : il n’a pas préparé son backlog et ne joue pas son rôle dans le Planning.
L’équipe est désengagée et démotivée : elle ne s’implique pas dans la réunion.
Le Scrum Master fait tout pour qu’à la fin du Sprint Planning son but implicite soit atteint : l’équipe s’engage sur un contenu de sprint qui a du sens. Il remplit l’espace pour que la situation soit la meilleure possible à court-terme.
Et le résultat est saisissant : le Scrum Master, en voulant remplir au mieux son rôle, empire les problèmes de départ car ni le PO ni l’équipe ne ressortent de cette réunion plus motivés et impliqués.
Cette solution est osée et difficile au démarrage, car cela signifie que lors de ce Sprint Planning, le Scrum Master doit accepter d’animer un Sprint Planning vide de sens et d’engagement de la part des participants. Peut-être même que l’équipe partira dans un sprint sans intérêt.
Mais c’est bien a priori en adoptant cette posture qu’il permettra de sortir de ces boucles amplificatrices du problème pour réussir à le résoudre.
Maintenant que je visualise le système et que j’ai pris conscience du levier du changement, je décide d’utiliser cet outil dans un entretien de coaching pour que le Scrum Master prenne lui aussi conscience de l’impact qu’il a sur le système.
Armé d’un feutre et d’un paperboard, je lui présente rapidement la façon de représenter (les variables du système, les impacts positifs ou négatifs), et nous représentons ensemble ce qu’il s’est passé pendant le Sprint Planning.
Nous voyons alors qu’en voulant bien faire, il bloque le changement, et qu’il est important qu’il travaille sur un changement de posture.
Ce qui m’a le plus marqué dans cette utilisation de l’outil, c’est sa neutralité.
En effet, sans cet outil j’aurais naturellement discuté de ce problème avec le Scrum Master. J’aurais pointé du doigt un problème (sa posture), ce qui aurait pu avoir comme effet de le mettre sur la défensive, de nous mettre l’un contre l’autre et de le bloquer dans un changement possible.
En objectivant le problème par une représentation commune du système, nous étions ensemble, l’un à côté de l’autre, en train de visualiser une situation, nécessitant peut-être un changement mais sans jugement.
Cette représentation met en lumière le fait que c’est presque “normal” qu’il ait ce comportement dans ce système (une équipe Scrum avec un PO peu impliqué et une équipe démotivée).
Le Scrum Master est acteur et peut bien sûr agir sur le système en changeant sa posture mais le système dans lequel il est empêtré a aussi un gros impact sur ce qui se passe : il induit le comportement du Scrum Master.
Le problème est global et donc pas focalisé sur le seul Scrum Master.
Je vous partagerai d’autres expériences de représentations systémiques, et comment je les utilise dans mes missions, dans de futurs billets…
Vos données sont traitées par Goood! afin de publier votre commentaire. Les destinataires sont Goood! et son sous-traitant en charge de la gestion du serveur web (Rapidomaine). Les informations nécessaire au traitement de votre demande sont marquées par un astérisque. Pour plus d'informations sur le traitement de vos données et l'exercice de vos droits, reportez-vous à notre politique de confidentialité.
[…] Source : Mon premier exemple de représentation systémique – Le Blog Goood! […]