Le déclic

En avril 2017, un déclic a eu lieu chez moi. Mon équipe et moi vivions un moment difficile. Le moral était au plus bas, nous étions en plein milieu d’une « death march« . Les heures supplémentaires abondaient, la satisfaction au travail n’était pas au rendez-vous. Les 4 premiers mois de cet emploi avaient été les plus beaux de ma carrière, et soudainement, je me retrouvais à aller travailler à reculons.

Mais que s’est-il passé?

Je me suis rendu compte à ce moment là que mon influence en tant que Scrum Master se limitait généralement à mon équipe et à mon environnement immédiat. Que je pouvais difficilement améliorer la culture globale dans laquelle baignait mon équipe. Au point où, turbulent comme je le suis, il me venait en tête des questions telles que : suis-je un bon Scrum Master? Est-ce vraiment ce que j’ai envie de faire? Est-ce ce que je devrais faire autre chose, et quoi?

Le pourquoi

Au même moment, je commençais à m’intéresser à Simon Sinek. Sa conférence et son livre « Start with why » me fascinaient. Sans tomber dans les détails, c’est la théorie selon laquelle les gens ne nous suivent pas à cause de ce que nous faisons, mais à cause de pourquoi nous le faisons.

C’est pour cette raison que, étant donné la situation, j’ai décidé de me demander « Pourquoi? », plutôt que « Quoi? ». Je n’avais pas encore la moindre idée à quel point cela aurait un impact, mais j’avais le sentiment profond que je devais trouver cette information à tout prix.

Le dénominateur commun

Pourquoi est-ce que je me lève le matin? Pourquoi est-ce que je me rends au travail chaque jour? Cela m’a pris plusieurs mois d’introspection avant d’avoir une réponse convenable.

J’ai commencé à récolter des données. À quelques reprises, j’arrivais à la maison et je disais « Ah c’était une BONNE journée aujourd’hui ». J’ai tenté de trouver le pattern, le dénominateur commun. Qu’est-ce qui rend une journée bonne, pour moi?

Après quelques semaines, le puzzle semble donner une réponse. Une bonne journée, c’était lorsque que j’avais eu l’occasion d’aider quelqu’un à améliorer son environnement ou ses conditions de travail. À prendre en main son avenir. Que ce soit dans mon équipe, à mon travail ou même à l’extérieur.

Le pourquoi, à tous les niveaux

Même si c’était une excellente piste, je voulais trouver où je me situais plus globalement avec mon pourquoi. Pour quelle cause noble est-ce que j’améliore l’environnement de travail de mon prochain? À quelle échelle puis-je faire une différence?

J’ai du appliquer mon raisonnement à plusieurs niveaux.

• Globalement, je veux changer le monde. Comme tout le monde.
• Je souhaite clore une fois pour toutes le « débat » à savoir s’il vaille vraiment la peine d’investir dans le bonheur des employés et la culture d’entreprise.
• Plus localement, je souhaite contribuer à faire de Montréal la ville où les gens sont les plus heureux au travail.
• Et dans mon environnement immédiat, je veux amener un maximum d’humanité au travail. Une nécessité qui, je trouve, se fait de plus en plus rare.

Vous aimez ce que vous lisez?
Reservez-nous pour une conférence sur le sujet!

Et puis après? Ça change une carrière.

Après une telle prise de conscience, les questions telles que « Que veux-je faire? » et « Est-ce que je fais la bonne chose » sont devenues obsolètes. Maintenant que mon « Pourquoi » était établi, j’allais tenter de consacrer un maximum de temps à l’appliquer.

J’ai pris le risque d’investir un certain pourcentage de mon temps de travail dans les membres de mon équipes, individuellement et en groupe, afin de les aider à prendre en main leur environnement de travail. J’ai également passé du temps avec des gens en dehors de mon équipe, et en dehors de mon entreprise, pour faire la même chose. Mon équipe a pris une tangente très positive, et a développé son niveau d’autonomie. Au niveau individuel, mes collègues commençaient à prendre leur destinée en main.

Je me suis rendu compte que 100% de la valeur humaine que j’apportais était créée par ce petit pourcentage de temps passé à aider mes pairs à se développer.

À ce moment, j’ai cessé d’être Scrum Master, et j’ai simplement commencé à être « Celui qui aide les autres à se développer ». Mon titre n’avait plus aucune importance, tout était dans le pourquoi.

J’ai complètement réécrit mon profil LinkedIn, retirant tout les buzz words techniques ainsi que la formule de rédaction professionnelle, aseptisée et froide. Au lieu de parler d’où je viens, j’ai commencé à parler de pourquoi je fais ce que je fais. D’une façon humaine et empreinte de ce qui me passionne.

Quelques temps plus tard, on m’appelle et on me dit « J’aimerais parler de ce en quoi tu crois. Nous croyons la même chose, et on a besoin de quelqu’un comme toi ». On m’offre un l’opportunité d’investir 100% de mon temps à aider des gens à se développer. J’accepte. Je suis maintenant gestionnaire de développement logiciel chez Marine Press. Ça aurait pu être n’importe quel titre, l’important est que mon rôle est d’appliquer à temps plein ce pourquoi je me lève le matin.

Je vous laisse sur cette citation qui résume assez bien ce que j’ai appris avec cette aventure.

Olivier Fortier

Propriétaire de Primos Populi, partenaire et coach chez Moabi. En tant qu’ancien gestionnaire, je préconise l’approche “les gens d’abord, et le reste suivra”. Mes sujets de prédilection sont la culture organisationnelle, le droit à l’erreur et l’abaissement du centre de gravité du pouvoir décisionnel. Je cultive l’épanouissement des gens.

www.primospopuli.com

Or, être Scrum Master c’est aussi être, comme j’aime l’expliquer, « un spécialiste des êtres humains dans un environnement technologique ». La formation de SM ne couvre que très peu les différents moyens d’assurer une bonne auto-organisation d’équipe, les approches pour engager nos coéquipiers, de s’assurer qu’ils s’approprient leur travail, etc.

Je me lance dans une grossière estimation : Dans 90% cas, les gens qui sont aujourd’hui des Scrum Masters ou Coach Agiles étaient auparavant soit des développeurs, des gestionnaires ou des chargés de projet. Pour certain, ils le sont devenus par choix, et d’autres se sont vu assigné ce rôle suite à une décision d’entreprise.  Il n’est pas rare, par exemple, qu’un développeur devienne SM de son équipe car il connaît davantage les processus Scrum. Ou alors qu’un chargé de projet devienne SM « par défaut » suite au passage de l’entreprise à l’approche Agile.

Or, d’où l’on vient dicte parfois où l’on va, et je crois que c’est un peu le cas des agilistes. Notre expérience du passé risque grandement d’influencer notre approche en tant que Scrum Master, et chacun risque de rencontrer des difficultés ou d’appliquer d’anciens réflexes en accompagnant son équipe. Comme en être conscient, c’est 50% du problème de réglé, je me suis dit que ça ne ferait pas de mal d’écrire à ce sujet.

J’ai fait une compilation de ce que je crois être « les qualités d’un bon Scrum Master / Coach Agile ». Je ne prétends pas avoir tout juste, mais l’idée est de voir quelles difficultés risque de rencontrer un Scrum Master en fonction de son « background » professionnel. Pour couvrir une majorité de cas, je vais surtout me concentrer sur ceux qui ont un background en développement logiciel, en gestion d’équipe et en charge de projet. J’y vais assez simplement, avec des listes d’avantages et inconvénients.

Être Scrum Master lorsqu’on a une expérience de développeur

C’est un cas très commun. Il n’est d’ailleurs pas rare qu’un développeur fasse office de Scrum Master à mi-temps. Je m’abstiendrai de me prononcer en profondeur sur cette pratique, ne l’ayant pas essayée, mais disons qu’un SM dédié peut avoir bien assez de travail pour ne pas avoir à coder, tout dépend des attentes de l’entreprise et de l’équipe.

Un ex-développeur aura de la facilité à :

• comprendre le volet technologique du produit, cela lui servira tous les jours
• trouver la balance entre qualité et efficience
• appliquer les concepts de simple-design et de refactoring, qui ne lui seront pas inconnus
• faciliter les processus nécessaires à l’assurance qualité
• appliquer et défendre les pratiques telles que le pair-programming et le peer code review

Un ex-développeur pourrait avoir de la difficulté à :

• gérer les relations interpersonnelles et les conflits s’il n’y est pas habitué
• assurer l’auto-organisation de son équipe si, par exemple, il était chef d’équipe et avait l’habitude de décider « qui fait quoi »
• garder en tête que le principe est plus important que la pratique
• être un agent de changement ou oser perturber l’ordre établi
• savoir laisser son équipe se planter quand nécessaire
• exercer son pouvoir d’influence
• pouvoir faire un suivi du sprint ainsi que des projections
• créer des chartes burn-up et roadmaps
• faciliter les relations avec le client

Être Scrum Master lorsqu’on a une expérience de chargé de projet

Cas typique suite à une gestion de changement dans une entreprise qui est passé du « waterfall » à l’agilité. Pour plus d’un, le chargé de projet peut aussi bien devenir Product Owner que Scrum Master, comme s’il s’agissait d’une pièce du jeu Tetris qui s’emboîte tout seul dans l’équation. J’ai eu de nombreux cas où cela a effectivement bien fonctionné, d’autres moins bien.

Un ex-chargé de projet aura de la facilité à :

• faire le suivi du sprint ainsi que des projections
• créer les chartes burn-up et les roadmaps
• faciliter la relation avec le client
• amener l’équipe à être orienté vers un objectif commun

Un ex-chargé de projet pourrait avoir de la difficulté à :

• gérer les relations interpersonnelles et les conflits s’il n’y est pas habitué
• assurer l’auto-organisation de son équipe et se retenir de déterminer « qui fait quoi »
• garder en tête que le principe est plus important que la pratique
• être un agent de changement ou oser perturber l’ordre établi
• savoir laisser son équipe se planter quand nécessaire
• balancer qualité et efficience
• être au service de l’équipe et non le contraire
• maitriser les concepts de simple design, refactoring, assurance qualité, pair programming
• laisser l’équipe estimer son travail

Être Scrum Master lorsqu’on a une expérience de gestionnaire

Ce cas-ci est beaucoup moins fréquent, et tout dépend aussi de quel genre de gestionnaire il est question. Prenons le cas d’une bonne gestion orientée vers les personnes. Quelqu’un ayant une bonne expérience de gestion d’équipe aura sans doute plus de facilité à saisir la dimension de leader engagé (servant leader).

Un ex-gestionnaire aura de la facilité à :

• gérer les relations interpersonnelles et les conflits
• assurer l’auto-organisation de son équipe et responsabiliser ses coéquipiers
• garder en tête que le principe est plus important que la pratique
• être un agent de changement ou oser perturber l’ordre établi
• savoir laisser son équipe se planter quand nécessaire
• exercer son pouvoir d’influence
• amener l’équipe à être orienté vers un objectif commun

Un ex-gestionnaire pourrait avoir de la difficulté à :

• comprendre le volet technologique du produit
• trouver la balance entre qualité et efficience
• appliquer les concepts de simple-design et de refactoring
• faciliter les processus nécessaires à l’assurance qualité
• appliquer et défendre les pratiques telles que le pair-programming et le peer code review

Au final, peu importe l’évolution de la carrière d’un Scrum Master, il sera amené à maitriser des éléments d’un milieu qui soit lui est étranger, soit qu’il ne maîtrise pas naturellement. Le plus important dans tout cela, est que l’agilité existe pour les gens et non pour les technologies. Sans coéquipiers, pas d’agilité, pas de Scrum, pas de logiciel. Le Scrum Master doit donc garder le cap sur le fait que des humains composent son équipe, et que c’est eux qu’il doit développer en priorité.

Je conclurai avec une citation que j’ai vu passer sur LinkedIn alors que je rédigeais cet article (la traduction est de moi), et qui résume assez bien, je crois, le défi premier de tout agiliste :

Merci à mon collègue Éric Laramée pour la citation.

Olivier Fortier

Propriétaire de Primos Populi, partenaire et coach chez Moabi. En tant qu’ancien gestionnaire, je préconise l’approche “les gens d’abord, et le reste suivra”. Mes sujets de prédilection sont la culture organisationnelle, le droit à l’erreur et l’abaissement du centre de gravité du pouvoir décisionnel. Je cultive l’épanouissement des gens.

www.primospopuli.com