Écrit par Sacha, Coach Agile

Aujourd’hui j’organise un atelier important pour nous. Suite à nos échanges, Dominique, qui pilote la DSI, m’a dit qu’il voulait que l’équipe soit libre, autonome. Le projet pilote “Journal de Bord” doit être exemplaire. Je l’entends encore me dire “il faut vraiment qu’on se jette à l’eau avec ce projet, tant pis si on commet des erreurs. Je ne veux pas d’un pilote tiède. Je veux qu’ils aient la liberté et l’implication qu’ils auraient dans une startup.”

Je pense qu’il faut que l’équipe pose les bases de cette autonomie, un contrat. Qu’elle se demande “Quels doivent être nos droits ?” et “Que nous engageons-nous à faire ?”. Comme dit l’oncle de Spiderman : un grand pouvoir implique de grandes responsabilités.

Je les rassemble tous. Nous commençons par un petit icebreaker, car tout le monde ne se connait pas personnellement. Chacun interviewe l’autre sur son parcours, son rôle tel qu’il/elle le définit, et sur une activité secrète que le reste de l’équipe ne connaît pas. Ensuite c’est l’intervieweur qui présente l’interviewé. 

Cela met une bonne énergie. On s’aperçoit que Morgan, le PO, vient de la biologie. Que Clarence et Noa pratiquent les jeux de rôles et pourraient le faire ensemble. Swann propose ses confitures aux parfums sophistiqués.

“J’ai discuté avec Dominique. Je lui ai parlé d’entreprise libérée, d’équipes auto-organisées, et il vous donne un mandat pour expérimenter, cela. Vous devez être une équipe autonome.

– Qu’est-ce que cela veut dire, autonome ?

– Que vous vous organisez comme bon vous semble pour atteindre vos objectifs et respecter vos contraintes.

– Tu peux nous donner un exemple ?

– Je pensais à un cas particulier. Imagine que l’on soit, dans quelques itérations, confrontés à un choix : reprendre notre façon de faire des tests automatiques ou délivrer plus de valeur.

– Oui. Et bien ?

– Et bien personne ne le choisira pour nous. Dans nous j’inclus le PO. C’est à notre équipe de se poser la question : pour atteindre mon objectif (délivrer un maximum de valeur au fur et à mesure du projet) est-ce que je consacre de l’énergie pour mieux automatiser les tests, en délivrant moins de valeur tout de suite ou bien est-ce que je fais ce qui me permettra de mieux maîtriser ma base de code et de fournir plus de valeur plus durablement. Une startup n’a pas un budget, un délai infini. Pourtant il faut bien investir parfois.”

Les équipiers se regardent, un peu perplexe.

“J’ai un autre exemple : l’un d’entre vous nous présente le framework Javascript X qui lui semble plus approprié pour nos besoins. Est-ce qu’on refactore tout ou est-ce qu’on reste sur l’ancien framework ?

– Mais comment peut-on décider ça ?

– A chaque décision clé de la vie du projet, votre Scrum Master convoquera l’équipe pour une discussion, afin d’aboutir à une décision. Chacun pourra donner son avis. Prenons un exemple : je pose la question “Est-ce que vous êtes tous partants pour que nous soyons autonomes et que nous définissions nos droits et devoirs dans un contrat avec Dominique ?” Si vous êtes pour, montrez un pouce vers le haut. Si vous êtes neutres, montrez un pouce horizontal. Si vous êtes contre, montrez un pouce vers le bas.”

Chacun vote. Il y a deux pouces neutres dans l’équipe.

“Qu’est-ce qui pourrait vous faire adhérer complètement ?

– J’ai un peu de mal à me projeter maintenant sur un contrat. Je ne sais pas bien comment nous allons fonctionner.

– Ok. Si je te dis que nous pourrons préciser ce contrat au fil des semaines ?

– Alors là je suis d’accord.”

Je prends une feuille de papier avec une liste de sujet et les balaye l’un après l’autre avec l’équipe. A chaque fois, Charlie, le Scrum Master, se prononce en dernier. L’équipe vote et entérine le sujet, et on passe au suivant.

Certains sujets sont faciles, comme le choix de la méthodologie. Personne ne viendra challenger l’équipe si elle introduit une dose de Kanban. On maintiendra forcément les revues car elles font partie de la visibilité de l’équipe et du produit auprès des autres équipes.

L’équipe choisira l’architecture, et la technique, et pourra en changer mais en mettant dans la balance le retard que cela implique en terme de valeur.

L’équipe fixera aussi le niveau de tests.

Plus complexe, le mode produit. C’est l’équipe qui mettra en production, qui devra s’assurer du bon fonctionnement, et assurer une surveillance et une permanence. Certains sont un peu réticents, mais nous finissons par trouver un terrain d’entente : nous prendrons le temps de préparer des scripts et des procédures.

Nous relisons ensemble le contrat, et planifions une rencontre avec Dominique pour le lui présenter.

Nous avons donné un outil à l’équipe pour qu’elle prenne son autonomie. L’autonomie ne se décrète pas, il faudra maintenir un environnement favorable à l’émergence de cette prise d’autonomie.

Photo by Johan Godínez on Unsplash