Blog

2018-06-06

Deuxième partie : la maison, un laboratoire pour le bureau

Dans la première partie, ‘Une famille est une équipe‘, je vous expliquai comment le coaching d’équipes et d’employés a influencé l’éducation de mes enfants. Bien sûr, le parallèle se limite au coach qui se cache derrière le parent: nous n’avons pas les mêmes responsabilités envers nos enfants que les employés que nous accompagnons et il ne s’agit évidemment pas d’infantiliser nos coachés… d’ailleurs, je parle à mes enfants comme à des adultes en devenir!

Avec nos coachés comme avec enfants, il faut savoir écouter plus que parler. Poser des questions, répondre à leurs questions par d’autres et les laisser trouver les réponses par eux-mêmes. Souvent, on doit leur apprendre à apprendre et souvent faire taire l’expert en nous qui croit déjà connaître la meilleure réponse à leurs problèmes.

Lire la suite

2018-05-23

Première partie : une famille est une équipe!

Quand j’ai commencé ma carrière de coach Agile, il y a 3 ans, j’ai très rapidement fait des liens, des parallèles entre ce nouveau rôle pour moi et mon rôle de parent. Non, je ne perçois pas mes clients comme des enfants! Par contre, en tant que parent, mon rôle est d’accompagner mes enfants (10 et 12 ans au moment où je vous écris) à devenir adulte, c’est-à-dire à développer des qualités comportementales dont ils ont tantôt envie (« quand je serai grand… »), tantôt pas du tout (ils voudraient rester enfants et en garder tous les avantages). Il en est de même pour beaucoup d’employés appelés à devenir Agile!

Une famille est une équipe et ses membres peuvent être accompagnés collectivement et individuellement!

J’ai ainsi tenté une première expérience basée sur la notion de valeur. Ce qui a de la valeur à mes yeux donnait des points : par exemple, mettre la table en équipe donne plus de points que le faire seul, car la collaboration, même si l’effort est moins grand, a un impact positif sur leur dynamique relationnelle. Mes enfants pouvaient ensuite utiliser ces points pour des activités dont ils fixaient la valeur (les points associés à la tablette ont occupé une bonne part des discussions!)

Lire la suite

2018-05-10

L’entretien et l’évolution

Slack Facilité, 20 avril 2018:

« Hey gang! Petite question du vendredi: l’un de nos projets part en mode support v1/dev v2 avec 40 personnes au total et 6 max pouvant être dédiées au support v1. Dans vos expériences, qu’avez-vous mis en place en terme de répartition de l’équipe de support? On a déjà pensé à 5 équipes de dev (SCRUM) + 1 équipe de support et améliorations (KANBAN), 6 équipes (SCRUM) avec un membre de support dans chaque équipe ou une équipe de support qui tourne, d’autres idées? »

Mets-en que j’ai d’autres idées!

J’ai même d’autres questions. À quel moment dans notre histoire commune est venue l’idée de séparer l’entretien de l’évolution? Séparer le développement de nouvelles fonctionnalités du support de celles déjà livrées?

On s’entend que d’un point de vue Fordisme, cette division verticale du travail a beaucoup de sens. On peut même étendre ce raisonnement en amont, appliquer la même équation à la conception (architecture, design, analyse) et structurer le travail comme une bonne et belle chaîne de montage où chacun cogne sur son clou avant de passer le travail au suivant.

En ajoutant une belle matrice d’imputabilité, on peut même forcer chaque division à accomplir sa tâche, et uniquement sa tâche, de manière standard et mesurée.

Lire la suite

2018-05-02

Planifications et estimations, pourquoi est-on en retard?

J’ai fait quelques petites lectures intéressantes dernièrement que j’aimerais bien partager avec vous. Je résume en fait une toute petite portion d’éléments provenant du cours en ligne « Agile Estimating & Planning » de Mike Cohn (Mountain Goat Software).

Indépendance des tâches

Il existe quelques raisons expliquant pourquoi les plans ne fonctionnent pas, notamment dans le domaine des technologies de l’information. La première est l’importance majeure qu’ont les dépendances entre les éléments du plan. Il est démontré que si chaque élément était TOTALEMENT indépendant des autres, alors les erreurs d’estimation (sur ou sous-évaluation) s’élimineraient entre elles et on aurait une distribution normale similaire à celle-ci :
DistributionNormale

Si c’était le cas, on pourrait alors avoir confiance aux estimés et aux plans.

Lire la suite

2018-04-18

Le déploiement continu : la licorne du DevOps.

(English follows)

De nos jours, le terme DevOps est partout. C’est le petit nouveau, la nouvelle star, dans toutes les entreprises technologiques. Avec des concepts de bases qui sont des piliers avérés d’une bonne culture d’ingénierie (équipes pluridisciplinaires, systèmes à flux tiré, transfert de connaissances à l’échelle et hyper-collaboration), il ne s’agit pas d’une surprise que les principes derrière ce « buzzword » font énormément de sens lorsque votre marché niche est la livraison logicielle et que vous ne vivez pas dans l’âge de pierre.

J’aimerais tout d’abord partager mon opinion sur un aspect particulier de ce nouveau désir des entreprises à « adopter le DevOps ». Le sujet émerge souvent lors de discussions entourant le délai de mise en marché. C’est par contre ce que j’aime appeler un morceau de licorne.

Lire la suite

2018-04-11

Cessez de jouer à Tetris avec votre temps

La surcharge est mère de tous les vices dans la philosophie Lean (Muri). C’est une plaie qui afflige la plupart des travailleurs intellectuels que je croise. La surcharge est tellement perverse que si vous en souffrez, vous ne vous en rendrez compte que trop tard. Voici quelques exemples de ce à quoi vous vous exposez:

  • Mauvaise prise de décision au quotidien;
  • Rater des dates limites;
  • Réduction globale de la productivité;
  • Augmentation de la charge mentale;
  • Fatigue professionnelle;
  • Aucun temps pour l’innovation;
  • Aucun temps pour l’apprentissage;
  • Aucun temps pour la collaboration (vous êtes un bloquant pour les autres);
  • Perte de motivation;
  • Attitude réactive et défensive, au lieu de proactive et constructive;
  • Sensation de perte de contrôle;
  • Perte d’efficacité dans vos communications (ex: envoi d’un courriel au lieu d’une conversation face à face, répondre sèchement par manque de temps, etc.)
  • Impossible de réagir efficacement aux imprévus/changements de plan;
  • Dégradation de votre santé mentale et physique;
  • Dégradation de vos relations professionnelles;
  • Être perçu comme quelqu’un de fermé et d’insensible aux priorités de ses collègues.

Lire la suite

2018-03-27

Nous, c’est différent…

Pour le commun des mortels, changer n’est pas quelque chose de facile à faire, voire impossible. Il n’est pas facile de faire des changements personnels et il l’est encore moins de faire des changements organisationnels en groupe, c’est-à-dire dans nos équipes de travail. Cela est plus difficile, car le changement repose bien sûr sur plusieurs individus et celui-ci doit être accepté par tous.

Plusieurs facteurs peuvent influencer ceci dans les équipes ou les organisations. D’abord, il y a la peur d’échouer. Pour certains, changement rime avec angoisse et anxiété. Quoi de mieux que nos bonnes vieilles pantoufles pour nous rassurer et nous sécuriser!

Il y a également la culture de l’entreprise. Si l’entreprise n’encourage pas le changement ou ne le soutient pas, il sera difficile pour ses joueurs de prendre de nouvelles initiatives, des risques, d’être créatif et d’apporter de nouvelles idées pour innover. Non seulement ces initiatives risqueraient de ne pas être reconnues, mais les employés qui les ont élaborées pourraient même être blâmés pour celles-ci. Les joueurs dans ce type d’organisation généralement préfèrent le statu quo.

Lire la suite

2018-03-27

Continuons d’évoluer, révisons notre utilisation des points de récits utilisateurs !

Relisez le guide Scrum. Il n’y a pas de notion de vélocité ou de points de récits utilisateurs. Ce fait, qui m’a été rappelé récemment par un collègue, m’a permis de réaliser les multiples biais injectés dans les fondamentaux Scrum et Agile pour répondre à des besoins de métriques.

Amusez-vous à lire cet article.

L’un des biais les plus flagrants est, pour ce billet, la notion de point pour un récit.

“Working software is the primary measure of progress.” – Manifeste Agile

Lire la suite

2018-03-14

Prendre des décisions Agile et Lean

Au delà des méthodes et des pratiques, il y a les concepts de base. De nos jours, Agile et Lean sont devenus des buzzwords qu’on utilise à toutes les sauces. Pourtant, quand on creuse la question, on réalise souvent que notre interlocuteur n’a aucune compréhension de la philosophie derrière les mots.

Que se cache-t-il derrière ces grands concepts? Qu’est-ce qui distingue quelqu’un qui est Agile et Lean de quelqu’un qui ne l’est pas?

La réponse réside dans la façon dont les décisions sont prises. Pour déterminer si une méthode, une décision ou une pratique est Agile et Lean, on doit la peser selon un filtre décisionnel bien précis.

Lire la suite

2018-03-07

Le parcours d’Eugénie dans son Agilité

Je vous présente Eugénie, chargée de projet depuis plusieurs années pour l’entreprise Complexe-cité. Sa direction, le bureau de projet et d’optimisation des processus (BPOP), relève de la vice-présidence stratégie et efficacité. Cette direction offre, entre autres, de l’accompagnement aux lignes d’affaires pour la réalisation de leurs projets, qui incluent souvent des solutions informatiques. Depuis bientôt deux ans, la vice-présidence des technologies de l’information a adopté l’approche Agile pour la plupart des réalisations des solutions informatiques. Bien qu’elle ait assisté à une formation de Scrum Master et quelques présentations sur l’approche Agile, Eugénie a encore de la difficulté à situer ses actions dans son référentiel de gestion de projet. Elle comprend le rôle du Scrum Master, mais le sien ne lui parait pas aussi clair, et sait encore moins comment s’y prendre avec le Scrum Master. Jusqu’ici, ses préoccupations ne lui avaient pas nui dans la prestation de ses services. Sauf qu’actuellement, elle travaille sur un projet stratégique pour l’organisation et le délai est très serré pour livrer la première version en production. Eugénie rencontre donc sa directrice pour lui faire part de ses préoccupations. Elle lui mentionne les points suivants :

  • « On me demande de faire une planification du projet, mais le focus des équipes est seulement sur la première livraison et le contenu peut changer plusieurs fois avant d’être fixé au début de l’itération. Cette situation amène plusieurs inconnus:
    • Qu’attend-on de moi au niveau de la planification?
    • Comment arrimer les différents contributeurs, affaires et TI?
    • Comment puis-je faire le suivi du projet de façon diligente?
    • Comment partager les responsabilités entre les Scrum Masters et moi comme chargé de projet?
    • On me dit que je peux assister aux mêlées quotidiennes de l’équipe, mais que je ne peux pas parler. Quelles sont les autres occasions dont je dispose pour m’adresser à l’équipe et leur partager des points qui me préoccupent sur leur progression?
    • Je dois préparer mes documents pour la reddition de compte et je ne sais pas trop ce que je dois présenter pour rendre visible la progression du projet. »

Lire la suite