Rappel de l’épisode précédent…

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 ?

Un premier exemple : la posture du Scrum Master en Sprint Planning

La situation

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 !

La représentation systémique

On y voit trois boucles amplificatrices en fait.

1ère boucle amplificatrice

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 l’équipe s’efface” : c’est un effet mécanique entre le temps de parole du Scrum Master et celui de l’équipe.
• “Plus l’équipe s’efface, moins elle s’auto-organise” : sans échange entre les membres de l’équipe, difficile pour elle de s’auto-organiser.
• “Moins l’équipe s’auto-organise, plus le Scrum Master prend de place” : en tant que garant de Scrum, le Scrum Master a comme but implicite de favoriser l’auto-organisation de l’équipe. C’est ce but implicite qui l’encourage à pousser l’équipe à s’organiser, donc à être plus présent encore.

2ème boucle amplificatrice

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” : effet mécanique entre le temps de parole du Scrum Master et celui du Product Owner.
• “Plus le Product Owner s’efface, moins de sens fonctionnel est donné au sprint” : c’est le PO qui donne du sens aux travaux de l’équipe, s’il est effacé, l’équipe risque de ne pas comprendre le sens de son travail.
• “Moins de sens fonctionnel est donné au sprint, plus le Scrum Master prend de place” : en tant que garant de Scrum, le Scrum Master a comme but implicite qu’il y ait un sens donné au sprint. C’est ce but implicite qui l’encourage à prendre la parole pour expliquer le sens du sprint, donc à être plus présent encore.

3ème boucle amplificatrice

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”

• “Moins de sens fonctionnel est donné au sprint, moins l’équipe peut réellement s’engager” : c’est le sens (fonctionnel, pour les utilisateurs) donné au travail effectué par l’équipe qui permet d’obtenir un meilleur engagement de l’équipe.
• “Moins l’équipe peut réellement s’engager, plus le SM prend de place” : en tant que garant de Scrum, le Scrum Master a comme but implicite d’obtenir l’engagement de l’équipe. C’est ce but implicite qui l’encourage à prendre la parole pour pousser l’équipe à s’engager sur quelque chose, donc à être plus présent encore.

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 !

Les problèmes de fond

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.

La solution de facilité

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.

Le levier du changement

Le changement de posture du Scrum Master

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.

Mon action de coaching

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.

Conclusion

Objectiver le problème

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.

Rendre au Système ce qui est au Système

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…