À la suite de cette rencontre, je me suis posé plusieurs questions. Puis, dernièrement, j’ai eu le plaisir d’échanger avec Rémi au sujet du leadership et du développement personnel des individus, et ce, dans les bureaux de La Maison des Leaders à Montréal. Nous partageons avec vous le premier segment vidéo d’environ 30 minutes dans lequel les thèmes suivants ont été abordés :

• l’intention de Rémi en lançant l’initiative de La Maison des Leaders et son fonctionnement;
• les conversations entre leaders et dirigeants ainsi que la zone « sécurisée » qui permet ces conversations;
• la transition vers un style de leadership plus équilibré.

Tout comme moi, j’espère que vous trouverez cette entrevue avec Rémi inspirante.

à bientôt,

martin

À propos de Rémi Tremblay

Rémi Tremblay a fondé Adecco Québec à 22 ans où il a œuvré pendant 17 ans jusqu’à occuper la présidence d’Adecco Canada et de ses 11 000 employés. On l’a reconnu comme l’un des douze bâtisseurs du Québec lors du Gala du commerce 2003 et il a aussi été reconnu parmi les 120 hommes et femmes au monde qui ont contribué à une éthique intégrale en entreprise par la Chaire de management éthique des HEC. Il est coauteur avec Linda Plourde de Découvrez le bonheur au boulot et avec Diane Bérard, du livre Les Fous du roi. Toujours avec Diane, il a publié un nouvel ouvrage en octobre 2009, J’ai perdu ma montre au fond du lac – Retrouver la tranquillité pour mieux gérer, mieux vivre.

L’Agilité n’apporte pas toutes les réponses. En fait, l’Agilité pose beaucoup plus de questions qu’elle ne fournit de réponses. Ce sont les réponses à ces questions qui permettent d’exposer les problèmes. Le plus gros défi, ensuite, est d’attaquer et de régler ces problèmes.

Prédire avec certitude l’état et la finalité d’un projet c’est comme tenter de prédire où passera un ouragan. Les météorologues utilisent le cône d’incertitude pour prédire où il passera. Cette méthode nous donne une bonne idée d’où il passera au cours des 2 prochains jours, mais plus on se projette dans l’avenir, plus ça devient flou. Pour demeurer le plus exact possible, ce cône doit être réévalué à chaque jour. La force de cette technique est qu’il est possible de différencier les zones qui n’ont aucune chance d’être touchées des zones qui peuvent l’être.

Dans nos projets, nous devons faire en sorte de tracer ce cône d’incertitude et de le réévaluer à chaque jour afin d’avoir une meilleure idée d’où va le projet. Pour ce faire, nous devons nous servir de ce que nous savons à ce moment-là. En fait, la notion de ce que l’on sait est un peu plus complexe que ça. Ce n’est pas simplement que l’on sait ou non quelque chose. La connaissance se révèle plutôt comme une matrice.

Prenez le tableau suivant :

Si on prend les intersections de chacune des lignes et des colonnes, nous obtenons notre niveau de connaissance. Par exemple, en haut à gauche, il y a nos certitudes, soit ce que je sais que je sais. À l’opposé, il y a les choses que je ne sais pas que je ne sais pas. À mon avis, c’est là que résident tous les problèmes que nous rencontrons dans nos projets.

Reprenons ce tableau en présentant les niveaux de certitude :

	Connu	Inconnu
connu	Connu	Prévisible
inconnu	Intuition	Risque

Ce qui est connu ne pose pas trop de problèmes, mais il ne faut pas non plus l’ignorer. Ce qui est prévisible doit être abordé pour éviter les problèmes. L’intuition, c’est cette petite voix qui nous met en garde que quelque chose ne va pas. Il est important de l’écouter, car malheureusement elle a trop souvent raison. Le risque est la partie la plus dangereuse. Nous devons tout faire pour réduire ce risque par du prototypage, des preuves de concept et des recherches. Si le risque pouvait être réduit à zéro, les projets seraient en tout temps une réussite!

Les tableaux ci-dessus découlent d’une page Wikipedia.

N’hésitez pas! Recommandez-nous un de vos contacts pour un des postes suivants : Scrum Master, coach organisationnel, coach d’équipe ou conseiller technologique.

Si la personne recommandée est embauchée, nous vous remettrons 2000 $. C’est aussi simple que ça!

Pour moi être agile c’est savoir s’adapter, éviter les mauvais coups. Un boxeur agile ne frappera pas nécessairement plus fort ou précis mais il recevra moins de coup. Un joueur de hockey agile ne comptera pas nécessairement plus de but mais il pourra se rendre plus souvent dans la zone pour le faire.

Un développeur agile n’est pas vraiment plus rapide qu’un autre, il sait juste éviter les récifs comme s’il descendait les rapides en kayak. Le développeur agile voit venir les coups et sait les éviter. Il sait même se mettre dans une situation où il sera en meilleure posture pour les éviter.

S’adapter c’est développer ses forces pour contrer les problèmes rencontrés. S’adapter c’est aussi laisser de côté ce qui ne fonctionne pas et utiliser ce qui fonctionne. La nature a évolué depuis des millions d’années comme ça. Il faut arrêter de faire ce qui ne fonctionne pas pour ne pas se faire déclasser pas les autres.

Démontrer

Un des préceptes des méthodologies agile est de produire des résultats démontrables à la fin de chaque cycle, ou sprint si on utilise la méthodologie SCRUM. La démo est une façon de présenter le travail accompli. J’insiste sur le terme accompli pour apporter la notion de done. Le donene veut pas dire que l’on peut le démontrer, ça veut dire que tous les critères que l’on s’est donnés sont respectés. La démo peut faire partie de ces critères.

L’objectif d’un sprint n’est pas la démo. L’objectif du sprint est de terminer les stories sur lesquels on s’est commis.

Trop souvent j’ai participé à des sprints où les priorités étaient dirigées par le désir de satisfaire les besoins de la démo sous prétexte que le VP allait y être. Les priorités doivent être dirigées par la valeur d’affaire. Le DDD ne veut pas dire Demo Driven Design mais bien Domain Driven Design mais ça c’est une autre histoire.

Voici ce que la liste indique :

• Pour certains projets, il est possible qu’un analyste ne soit pas requis. Cela est possible dans le contexte où les développeurs ont une capacité d’analyse suffisante ou lorsque le responsable de produit est en mesure de rédiger par lui-même le carnet de produit.
• Dans les projets plus complexes, l’analyste peut être un facilitateur capable d’élaborer une vision unique. Cela peut s’avérer nécessaire lorsque plusieurs parties prenantes au projet expriment des perspectives et des besoins contradictoires.
• L’analyste peut tenir le rôle de responsable de produit. C’est possible s’il connaît suffisamment le domaine d’affaires et si on lui reconnaît les droits de définir et d’ordonner le carnet de produit.
• Pendant une absence du responsable de produit, l’analyste peut tenir le rôle de suppléant. C’est également une option lorsque le responsable de produit ne se trouve pas sur le même site physique que l’équipe de développement.
• L’analyste peut augmenter la disponibilité et l’efficacité du responsable de produit en devenant son bras droit. Cela permet au responsable de produit de dégager du temps, n’étant plus seul pour entretenir le carnet de produit, de répondre aux questions des développeurs et d’évaluer les résultats des itérations.
• L’analyste peut être le coach d’une équipe. Cela est utile lorsque le responsable de produit maîtrise le domaine d’affaires, mais qu’il a une expérience limitée en réalisation de projets de TI, ou lorsque l’équipe de projet ne connaît pas le domaine d’affaires.

Personnellement, j’ai pu observer chacune de ces propositions dans le cadre de mes mandats d’accompagnement. Ce qui manque à mon avis pour compléter la réflexion de l’adaptation du rôle, c’est la détermination des autres disciplines de développement qui sont à la fois utiles à l’équipe et habituellement une source d’intérêts pour les analystes.

Martin sera chargé de solidifier et de promouvoir les services de développement de Pyxis en misant sur la « saveur » qui nous distingue : l’Agilité.
« Dès le début de mes discussions avec des membres de Pyxis, j’ai vu l’Agilité à l’œuvre. À Pyxis, il y a une concentration de talents assez remarquable, et j’avoue que c’est très rassurant. Je suis très heureux de joindre cette équipe qui ne va certes pas cesser de se faire remarquer », indique Martin Landreville.

Martin Landreville
Martin compte plus de 22 années d’expérience en développement logiciel. Au cours de sa carrière, il a géré de nombreuses équipes de développement et de gestion applicative. Il a participé à la réalisation de projets extraterritoriaux avec un centre de développement à Bangalore en Inde.

Martin a amorcé sa carrière à titre de développeur pour ensuite se concentrer sur le développement client-serveur et la création d’équipes de développement responsables de la réalisation de projets de moyenne et grande envergures. De plus, il a offert de la formation sur le développement orienté objet et sur le développement client-serveur, et ce, au Canada et aux États-Unis. Depuis plus de 15 ans, il se concentre sur la gestion d’équipes de développement et de gestion applicative et sur la mise en place de processus permettant la prise en charge de portefeuilles d’applications. Avant d’arriver à Pyxis, il a occupé différents postes de gestion chez Fusepoint Managed Services, CGI, IMRglobal et Visual Systems.

Tout d’abord, nous souhaitons embaucher plus de 20 personnes au cours des prochains mois afin d’aider les organisations à adopter des méthodes innovantes pour accroître de façon importante la performance. Les rôles sont variés. Nous sommes à la recherche de conseillers d’expérience (coach organisationnel Agile, coach d’équipe Agile et Scrum Master), de développeurs de logiciels et de personnel administratif (chef du marketing et des communications et gestionnaire de la marque et directeur de la division des services-conseils). D’autres postes seront ouverts sous peu.

Si votre emploi actuel ou votre lieu de travail ne vous permet plus de croître professionnellement (voire personnellement) ou si vous êtes réellement à la recherche de nouveaux défis, vous devriez consulter nos 10 postes disponibles. Avant de décider si un des emplois vous convient, vous pourriez souhaiter voir si notre organisation innovante est pour vous.

C’est plus qu’un emploi; c’est une mission.

Il y a quelques mois, nous avons redéfini notre énoncé de mission afin qu’il reflète bien ce que nous faisons et aussi ce qui nous passionne. Voici notre nouvelle mission : « À Pyxis, nous produisons pour nos clients des niveaux de performance sans précédent. Nous instituons des environnements qui déclenchent la motivation et le dépassement de chaque être humain. » N’aimeriez-vous pas aider les gens et les organisations à se développer?

Nous offrons une option aux emplois traditionnels.

C’est vrai, certaines choses que nous faisons sont traditionnelles. Toutefois, aider les gestionnaires, gestionnaires de projet et membres d’équipe à développer leurs compétences et à mettre en œuvre des environnements et des méthodes qui les motivent, c’est cool. C’est un peu comme un tour de montagnes russes – parfois, ça donne un peu mal au cœur, mais en général, c’est grisant. Lorsqu’on voit le sourire des gens, ça donne le goût de retourner faire un tour…

Avoir du plaisir, c’est exigeant.

Pour certaines organisations, ce qui rend le travail plus agréable, c’est d’avoir accès à un hamac ou à une table de baby-foot. On est bien d’accord que 15 minutes passées à jouer au baby-foot ou au PlayStation, c’est vraiment plaisant. Toutefois, nous préférons un autre genre de plaisir – celui d’accomplir quelque chose d’important tout en développant nos compétences avec des collègues chevronnés et en étant reconnus pour nos contributions. Et nous sommes convaincus que faire cela pendant 7 heures et demie par jour, c’est encore mieux que 15 minutes à jouer au ping-pong.

C’est votre carrière, faites ce que vous voulez.

Qui n’a pas d’aspiration professionnelle? Si vous souhaitez atteindre les buts personnels que vous vous êtes fixés et avoir un plan vous permettant d’y arriver, nous serions heureux de vous aider à y parvenir. Désirez-vous suivre un cours de formation en particulier? Développer certaines compétences? Nous vous aiderons à déterminer quel est le meilleur parcours pour atteindre votre but tout en vous soutenant le long de celui-ci.

Agile, ce n’est pas qu’un mot à la mode, c’est une philosophie.

Tout comme vous, nous entendons parler d’organisations qui ont adopté une approche Agile. Nous croyons que faire de l’Agilité ce n’est pas la même chose qu’être Agile. « Être Agile », c’est plus qu’assister quotidiennement à une réunion debout (mêlée quotidienne) et appeler le patron « Scrum Master ». « Être Agile », c’est vivre les valeurs et principes de l’Agilité, et ce, jour après jour.

Nous sommes d’accord avec Dan Pink lorsqu’il dit que l’autonomie, la maîtrise de la situation et l’intention sont les principaux facteurs de satisfaction au travail. N’aimeriez-vous pas voir comment l’Agilité pourrait avoir un impact sur votre carrière?

Cynthia complète 8 des 9 tâches qu’elle s’est engagée à terminer. Est-ce un problème?

Patrick rate son objectif de ventes de 0,5%. Devrions-nous accepter cela?

En tant que gestionnaires, nous sommes rémunérés pour nous assurer que les gens livrent ce sur quoi ils se sont engagés (entre autres). C’est ce que je définis comme «l’intégrité» – dire ce que nous allons faire et faire ce que l’on a dit. S’assurer que les gens fonctionnent avec intégrité est une tâche difficile!

Revenons à nos 3 questions originales. Qu’auriez-vous fait? Accepter la situation ou faire quelque chose?

Accepter la situation est la chose la plus simple à faire. Cela nous laisse sortir du rôle difficile de faire respecter les engagements. De cette manière, nous restons un bon gars et nous ne modifions pas la perception qu’ont nos collaborateurs de nous. Malheureusement, il y a un inconvénient. Quand nous laissons aller de telles situations, nous acceptons – en fait, approuvons – le fait que des promesses seront faites et qu’elles seront brisées. Cela crée un environnement où les choses sont difficiles à prédire et où la cohérence devient inexistante.

Faire quelque chose au sujet de la situation et le respect des engagements est beaucoup plus désagréable. Cela nécessite un travail et des conversations potentiellement difficiles avec les gens qui ont brisé leurs engagements. Faire quelque chose au sujet de tels incidents exige que les personnes soient responsables pour leurs actions et en assument les conséquences. Il y a aussi le risque perçu de ne pas être aimé par ses employés, d’être trop dur et déraisonnable. Le point est qu’il est de notre responsabilité en tant que gestionnaires de nous assurer que les engagements soient clairement définis et respectés de façon uniforme afin d’éviter toute confusion dans notre milieu de travail. Dès que nous laissons quelqu’un d’enfreindre une règle – peu importe l’importance de l’incident – nous ouvrons fondamentalement la porte à des incidents de plus en plus importants. Comme une boule de neige dans une avalanche, il est préférable d’intervenir immédiatement, plutôt que d’attendre que toute l’organisation soit ensevelie sous ces dysfonctionnements.

Lorsque vous avez répondu à ma question, si vous avez choisi la réponse «ça dépend», vous vous êtes essentiellement donné bonne conscience et vous avez tenté de masquer le fait que vous endossez un tel comportement de votre organisation. Comme un de mes collègues dit toujours «En plus de 30 ans comme gestionnaire, je n’ai jamais – jamais – entendu une mauvaise raison pour quelqu’un de briser son engagement». Les choses arrivent et les gens vont parfois briser certaines règles. Cela, en soi, n’est pas un problème. Comme gestionnaire, notre rôle est de déterminer les moyens pour faire face à la rupture des engagements et à apprendre aux gens à renégocier leurs engagements à l’avance, au lieu d’après les faits, lorsque l’engagement n’a pas été respecté.

Quant à moi, malgré le fait que je suis humain et souhaite aussi être apprécié par mes collaborateurs, j’ai besoin de me rappeler que mon rôle est d’être l’arbitre et de faire respecter les règles afin que chacun puisse faire son travail dans un environnement qu’il comprend bien. En tant que gestionnaire, je ne serai peut-être pas aimé par tous les gens et dans toutes les circonstances quand je demande le respect des engagements, mais au moins, je vais être respectés pour avoir fait mon travail.

L’événement débutera à 8 h, pour une durée de 2 heures. Un petit déjeuner sera servi.

Inscrivez-vous maintenant, les places sont limitées.

Au plaisir de vous y voir!

Les 29 et 30 novembre auront lieu les Tech•Days à Montréal. Éric de Carufel y présentera les 5 meilleures façons d’améliorer son code. Le but de cette présentation est de vous aider à améliorer le vrai code de production.

Soyez-y!
https://payment.techdays.ca/fr/venue