À l’époque, j’étais déjà gestionnaire d’une équipe de développement front-end travaillant dans un environnement Agile. Ce n’est que des années plus tard, en racontant ma remise en forme à des collègues, que j’ai fait le lien entre l’Agilité et ma perte de poids. J’ai réussi à faire 6 parallèles importants entre l’Agilité et la façon dont je m’y suis pris pour réussir cet exploit personnel.

1. L’état d’esprit est d’une importance capitale

En Agilité comme en perte de poids, tout dépend de l’état d’esprit. Bien sûr, il y a des processus, mais dans les deux cas, il ne servent à rien si nous n’avons pas le « mindset » nécessaire.

L’état d’esprit dans la perte de poids

Au début de mon programme, nous étions un groupe de 18 personnes. À la fin du programme, nous étions 8. Il y avait donc 10 personnes qui n’étaient pas réellement prêtes à modifier leur style de vie pour être plus en forme. Seuls ceux qui avaient atteint un état d’esprit de croissance (versus un état d’esprit fixe) ont été jusqu’au bout du programme de 9 mois.

Ces personnes ayant abandonné le programme, qui ont fait de très gros efforts, ont payé cher pour finalement revenir à leurs vieilles habitudes sans profiter des avantages qui était à leur portée. Si l’effort physique est difficile, l’effort mental l’est parfois encore plus.

L’état d’esprit dans l’Agilité

Beaucoup trop d’entreprises « font » l’Agilité sans réellement vouloir changer leurs vieilles habitudes qui sont bien ancrées, et difficiles à déloger. Ce sont généralement les entreprises qui finissent par dire « l’Agilité, ça ne fonctionne pas » et reviennent à un train de vie où ils sont confortables. L’agilité ne fonctionne pas, vraiment? Ou n’étiez-vous pas prêt à changer votre style de vie pour réussir? Car l’Agilité, par sa définition, est la capacité de s’adapter en fonction de besoins en perpétuel changements.

C’est maintenant un consensus qu’appliquer les processus Agiles sans apporter des changements radicaux à la culture d’entreprise n’apporte pratiquement aucun des avantages de l’Agilité, sinon un certain cynisme chez les développeurs qui trouvent que « même quand ça change, rien ne change vraiment ».

2. La motivation est essentielle, mais c’est la discipline qui fera la différence

Partout où je passe, j’essaie de faire mon maximum pour comprendre les motivations intrinsèques de mes collègues. La motivation intrinsèque, possible lorsqu’on retrouve la combinaison « maitrise, autonomie, sens », est essentielle pour moi si je veux m’accomplir dans mon travail. Il en allait de même pour la perte de poids.

La motivation peut réellement donner le coup d’envoi spectaculaire à toute ambition professionnelle et individuelle. C’est d’ailleurs elle qui fait que je sois aussi actif sur LinkedIn sur le sujet de l’Agilité et de la culture d’entreprise. Cependant, c’est en prenant des habitudes et en créant une routine que je parviens à garder le cap.

Motivation et discipline dans la perte de poids

Un ami à moi m’a répété quelques fois : « Je te regarde aller, Olivier, et je suis vraiment très motivé! Moi aussi je vais perdre du poids comme toi! »

Après la 3ème répétition de cette phrase en quelques jours, je lui ai dit « Cesse d’être motivé et fais-le! ». Il a maintenant perdu 100 lbs (45 kg).

La motivation est essentielle, c’est un peu comme le pied qui appuie sur l’accélérateur. Elle donne la poussée initiale. Cependant, c’est la discipline et la routine qui feront le reste du travail. Je me suis rendu compte que si je n’avais pas de moments précis et récurrents pour faire du sport, je finissais par me trouver des excuses pour ne pas en faire. Alors j’ai simplement mis dans ma semaine 4 plages horaires immuables réservées au sport. Pas besoin de me poser la moindre question, de me demander si je devais y aller ou pas : j’y allais les lundis, mercredis, vendredis soir après le travail, et le dimanche matin. Un point c’est tout. Dès que je m’éloignais de cette routine, je devais retravailler sur ma motivation.

Motivation et discipline dans l’Agilité

Dans certaines approches Agiles, telles que Scrum par exemple, c’est cette routine qui fait que les cérémonies sont un succès. La mêlée quotidienne a lieu tous les jours, au même endroit, que tout le monde y soit ou non. Cette routine réduit de beaucoup la complexité. On n’a pas à se demander « C’est à quelle heure aujourd’hui? Où c’est aujourd’hui? Qui vient aujourd’hui? ».

C’est encore mieux si on a la chance de mettre les séances de planifications, les revues et les rétrospectives à des moments récurrents. Moins l’équipe se pose de questions, plus elle sera engagée dans ces cérémonies qui deviendront des réflexes.

3. Les personnes davantage que les processus

La première valeur du manifeste de l’Agilité, et aussi celle qui me tient le plus à cœur. Comme ce sont des gens qui développent des logiciels (et aussi des gens qui se mettent en forme), on doit heureusement (malheureusement pour certains) considérer les personnes en premier, les processus ensuite.

Personnes et processus dans la perte de poids

À deux reprises, j’ai donné des conférences suite à ma perte de poids. Mon audience était composée des nouveaux s’étant inscrit à ce programme (l’accès aux conférences fait partie du forfait).

J’ai malheureusement eu à leur annoncer qu’il n’y avait pas de solution miracle pour perdre du poids. Il fallait manger mieux, et faire du sport. On ne s’en sort pas. Cependant, il n’existe aucune formule magique qu’on peut appliquer à tout le monde (même le guide alimentaire canadien n’est pas un « one size fits all »). Les gens sont différents et ont des besoins différents. Il faut donc travailler avec des experts, essayer des choses, garder ce qui fonctionne et cesser ce qui ne fonctionne pas pour une perte de poids efficace.

Personnes et processus dans l’Agilité

Exactement la même chose. Il y a des compagnies qui tentent de vendre des processus efficaces. Cela doit être difficile, puisqu’il y a des gens qui travaillent dans ces processus. Ce qui fonctionne pour une équipe ne fonctionnera peut-être pas pour l’équipe d’à côté.

Donc, un peu par paresse, je peux pratiquement copier le paragraphe de la section précédente :

Il n’existe aucune formule magique qu’on peut appliquer à tout le monde. Les gens sont différents et ont des besoins différents. Il faut donc travailler avec des experts, essayer des choses, garder ce qui fonctionne et cesser ce qui ne fonctionne pas pour développer efficacement des logiciels.

4. Prises d’actions pour s’améliorer

C’est bien connu, on ne peut s’attendre à des résultats différents en essayant toujours la même chose. Il existe tout plein de citation à ce sujet. Par exemple :

« La définition de la folie, c’est de refaire toujours la même chose, et d’attendre des résultats différents. » – Albert Einstein

« On ne crée pas un nouveau trou en continuant de creuser toujours le même trou. » – Edward de Bono

Prises d’action dans la perte de poids

Dans la vie, j’ai tendance à utiliser ce qui fonctionne bien pour moi. Si j’aime une certaine routine de sport et que je vois une différence, je colle à cette routine. Parfois je déroge pour faire changement, et je reviens à ma routine. Cependant, si je vois que la routine ne fait plus effet ou n’a plus d’impact, je change.

À un certain moment, dans la perte de poids, on atteint un plateau. Notre corps nous dit « Ah non, je perds tellement de poids, je dois être en danger. Je vais garder toutes ces calories et cesser de brûler, juste au cas ». Un bon moyen de casser ce plateau est de « troller » le corps en mangeant différemment, et en faisant des sports différents. Il est donc important de s’inspecter régulièrement pour voir comment briser les lignes droites, et la stabilité.

De petits changements réguliers, et une mesure de l’impact de ces changements sont de mise. Si ça marche, on continue. Si ça ne marche pas, on arrête.

Prise d’action dans l’Agilité

Les rétrospectives sont pour moi les cérémonies qui ont le plus de valeur. Un moment réservé que pour s’inspecter en tant qu’équipe, à contempler ce qui fonctionne et ce qui ne fonctionne pas, et à prendre des actions concrètes pour s’améliorer. Amélioration continue, n’est-ce pas beau?

Il existe toute une panoplie de métriques qu’on peut regarder pour voir si l’équipe stagne, si elle a des problèmes, et identifier des pistes d’amélioration. Ne pas tirer profit de la rétrospective est la plus grave erreur qu’une équipe Agile puisse faire. Autrement, c’est à se demander pourquoi essayer d’être Agile!

5. Mesurer l’impact d’abord

Des chiffres. Qui n’aime pas mettre des chiffres et mesurer son avancement et le résultat de ses efforts?

Mesurer l’impact dans la perte de poids

Lorsque j’ai commencé ma transformation, je mesurais tout : durée de l’activité, calories brûlées, poids, BMI (IMC), etc. Toutes ces mesures avaient beaucoup de valeur pour moi. Cependant, aucune d’elles n’étaient réellement tangibles. Même le poids perdu ne représentait pas une mesure tangible. C’était un chiffre. On ne voyait pas l’impact sur mon corps.

C’est lorsque j’ai commencé à pouvoir porter ma ceinture en utilisant de nouveaux trous que j’ai compris ce qu’était l’impact. Quand j’ai commencé à porter des t-shirt d’une, deux et trois tailles plus petites.

Toutes les autres métriques permettaient de mesurer … n’importe quoi sans rien vouloir dire. Il n’y avait pas nécessairement de lien de causalité. Au mieux je pouvais voir poindre des patterns et essayer de nouvelles choses. Mais l’impact sur mon corps était la seule mesure qui avait de la réelle valeur à mes yeux. Tous les efforts donnés prenaient ancrage dans la réalité à ce moment-là.

Mesurer l’impact dans l’Agilité

Quelque chose qu’on apprend à faire lorsqu’on est Scrum Master, c’est de récolter des métriques. Vélocité, indice de bonheur, charte de burndown, maturité d’équipe, nommez m’en!

Les équipes, les Scrum Masters, la direction, tous aiment mesurer tout ce qui est possible de mesurer, parce que cela donne une impression d’être en contrôle. Bien des mesures servent à identifier l’émergence de patterns et à générer des discussions afin de pouvoir s’améliorer.

Cependant, beaucoup de mesures n’ont que très peu de valeur pour tout le monde en réalité. La vélocité, par exemple, peut servir aux équipes à mesurer la stabilité de livraison, à faire des projections. Elle ne raconte pas cependant l’impact pour le client, la réelle valeur qui doit être mesurée pour un client satisfait.

Ne prendre en compte que le poids lors de notre mise en forme est une erreur. Et comparer le poids d’une personne à l’autre pour mesurer leur forme n’a aucun sens. Une personne de 220 lbs (100 kg) peut être bien plus en forme d’une personne de 180 lbs (80 kg). Il en va de même pour la vélocité. Prise à elle seule, elle n’a aucun sens, et comparer des équipes de par leur vélocité est preuve d’un manque de vision grave, d’un focus sur le mauvais objectif.

6. Rythme soutenable

Vouloir trop en faire à la fois, prendre de trop grandes bouchées, travailler fort coûte que coûte. Les effets négatifs et pervers de cette approche sont bien connus, il en va de soi dans nos deux contextes.

Rythme soutenable dans la perte de poids

Il est bien connu qu’une perte de poids trop rapide et drastique (à moins d’une chirurgie) risque de causer une reprise de poids tout aussi rapide si l’on ne garde pas le train de vie ayant favorisé la perte. Une diète extrême accompagnée d’efforts physiques intenses vont définitivement faire perdre du poids, mais si jamais on arrête, le corps sort de son état d’urgence et entre en mode « j’accumule tout ce que je peux, au cas où cela se reproduit ».

À la longue, le corps humain a besoin de ses calories et de repos. En faire trop est non seulement malsain mais mauvais pour la santé. L’important est d’y aller à un rythme soutenable. Faire du sport à une fréquence constante pouvant s’ajuster à notre mode de vie changeant. Manger sainement sans nécessairement se priver de tout ce que l’on aime. Une perte de 2 lbs (un peu moins de 1kg) par semaine est idéale.

Rythme soutenable dans l’Agilité

Pour exactement la même raison que ci-haut, vouloir en faire trop c’est se nuire à long terme. Une équipe qui s’engage à faire trop de travail dans une itération Scrum, par exemple, ne réussira probablement pas à tout livrer à moins de faire des heures supplémentaires. Si c’est le cas, non seulement ils créent un précédent, font mentir les métriques, mais en plus créent des attentes plus grandes envers leur propre productivité. Si cela continue plus longtemps, l’équipe s’épuisera.

Une bonne équipe doit garder le focus nécessaire pour maintenir un rythme soutenable et rester hors de tout état d’urgence permanent.

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