Heu! non, réécris-le

Oncle Bob (Monsieur Robert Cecil Martin pour les autres), mentionne :

Si tu penses commenter ton code, c’est sans doute que c’est mal conçu, alors réécris-le, ne le commente pas.

Cette phrase prend une grande place dans le rôle du professionnel TI que nous sommes.

Une devise de scout,

Nous quittons le camp plus propre que lorsque nous sommes arrivés.

Je suis dans le coaching Agile depuis quelques années, et il ne passe pas une journée où je dois répéter ces devises :

« Ce code est mal fait, je vais ajouter un commentaire pour le prochain qui va essayer de le comprendre » me dit un développeur tout souriant.

« Heu! Non, réécris le code, ne le commente pas. »

« Argh! la documentation n’est pas à jour » me dit l’analyste « Je vais laisser une note. »

« Merci du commentaire, maintenant mets-le à jour, et n’écris pas ta note. »

« OK!, si l’utilisateur active le bouton ‘non’, c’est parce qu’il doit changer la valeur d’un champ. Mais comment saura-t-il?  » demande le PO. « Ce n’est pas grave, nous allons écrire un texte dans l’écran pour l’expliquer » mentionne le rédacteur.

« Heu! Non, concevez la bonne interface graphique. »

Il n’y a pas de propriété intellectuelle, ce qui appartient à la communauté (projet, organisation, etc.) peut être modifié par celle-ci en tout temps. Vous allez me dire que vous n’avez pas le temps, bien alimentez votre carnet de dettes, car c’est bien ce que c’est.

« Fred, j’ai trouvé quelque chose pour bonifier ton texte. Je vais te laisser une note en bas dans la zone des commentaires. » Me mentionnez-vous. « Heu! non, modifies-le toi-même et laisse faire le commentaire. » Je vous répondrai bien, si ce n’est des contraintes de l’outil 😉

Nouvelles du 14 décembre 2015

14 Décembre 2015

Aujourd’hui dans l’actualité Agile de Facilité Informatique:

  • Date confirmée pour la formation «Planification et suivi de projet Agile»
  • Définition de prêt, les 6D de l’auteur Claude Aubry
  • Nouvelle conférence technique organisée par l’Agile Alliance
  • Réinventer les organisations pour l’Agilité de Michael Sahota
  • Qu’est-ce qu’un leader Agile de Henrik Kniberg
  • Convergeons-nous vers un Agile 2.0?
  • Vers un ordre professionnel?

Lire la suite

4ième itération de mon livre

Après 11 mois sans publier une itération, je lance aujourd’hui la 4ième itération de mon livre  So You Want To Be A Hero – Soft skills at the core of Agile software development.

J’ai en effet débuté la rédaction d’un livre sur le savoir-être pour membres d’une équipe Agile en novembre 2014. J’y ai publié ma première itération avec seulement 10 pages grâce à la plate-forme Leanpub. J’ai eu près de 150 téléchargements et 20$ en financement. Cela a dépassé mes attentes, moi qui croyait que ma mère allait être ma seule lectrice. J’ai donc été propulsé à écrire une deuxième (décembre 2014) et troisième (février 2015) itération. En avril 2015, j’avais 200 téléchargements et 100$ en financement. Voici une capture d’écran de ma page de statistiques sur Leanpub.com:

LeanPubReaders LeanPubRoyalties

Bizarrement, peu de gens m’ont envoyé des commentaires à propos de mes publications. Cependant, les gens ont voté avec leur porte-feuille. Certaines personnes me donnaient 5$ ou 10$ sans aucun commentaire.

Au lieu d’écrire un livre d’un bout à l’autre et de le publier (la méthode traditionnelle), j’ai opté pour l’approche itérative. Grâce à la plate-forme Leanpub, il est possible de publier des itérations de son livre pour y obtenir des commentaires ainsi que du financement. On assigne un prix suggéré au livre. Les early-adopters paient ce prix et recevront en échange les publications subséquentes gratuitement. Je recommande à tous cette merveilleuse plate-forme basée sur les principes du Lean Startup.

Pourquoi ce si long délai entre la 3ième et 4ième itération? J’étais sur un autre projet de démarrage d’entreprise cet été, c’est-à-dire de la crème glacée à l’azote liquide. Le projet allait bien jusqu’à ce que j’endommage l’équipement. Avec l’arrivée de l’automne, je me suis donc remis au projet du livre.

Pendant l’écriture de mon livre, je ne veux pas que mon livre devienne un autre livre dans le magasin électronique d’Amazon. Je suis tombé par hasard sur le dernier livre de Seth Godin, It’s Your Turn. C’est un livre tout à fait génial pour sa mise en page unique. J’ai donc voulu faire la même chose que Seth en terme de format, c’est-à-dire un livre unique où chaque page est unique. Je me suis donc associé avec Nadège Dionne-Tremblay pour m’aider à réaliser une version papier que nous bâtissons de façon itérative et incrémentale. Nadège bâtit donc un document de travail qui, d’itération en itération, évoluera jusqu’à la publication finale. Nadège est très créative où elle travaille fort pour transformer le contenu électronique dans un format papier unique et percutant. Vous retrouvez donc deux formats aujourd’hui:

Lorsque le livre sera publié dans son entièreté en novembre 2016, vous aurez l’option d’acheter la version électronique et/ou la version papier. En étant sur le bureau de vos collègues, et par son style unique, j’espère que la version papier produise des conversations sur les thèmes qu’il contient.

Comme toujours, vous êtes les bienvenus pour réviser le contenu du livre ainsi que commenter la mise en page de la future version papier. Après tout, les bénéfices de l’approche itérative et incrémentale feront que ma prochaine itération sera encore meilleure que celle-ci.

Notes de lecture : Lean Change Management

Nous avons beau avoir de bonnes intentions, être passionnés d’Agilité et dévoués à nos clients, mais l’humain étant ce qu’il est, il est fort difficile de prévoir comment il peut changer !

Comme dans tout bon projet informatique, on ne peut donc pas tout prévoir en détails la planification de la gestion du changement. Pour surpasser les résistances et obtenir des implémentations de changement avec succès, on doit donc adapter les techniques traditionnelles de gestion du changement en y mettant un peu d’Agilité et du « lean ». On ne peut pas tout savoir ou prévoir au départ et il nous faut l’accepter. On doit donc se baser sur les principes et valeurs Agiles pour guider nos actions dans le changement.

C’est le sujet principal du livre « Lean Change Management – Innovative Practices for Managing Organizational Change » dont je vais vous parler aujourd’hui.

Son auteur, Jason Little, est un canadien, ancien développeur et maintenant conseiller en gestion du changement, il a mis à l’épreuve les différentes techniques décrites dans son livre pour une organisation publique canadienne.

Bien que ce soit un petit livre, il fait un peu moins de 200 pages, ce dernier est quand même rempli de processus, frameworks, conseils et autres outils pertinents pour une gestion du changement « lean » et Agile. Tout cela s’articule autour du cycle intitulé « Lean Change Management » que voici :

lean-change-cycle

En gros, voici ce que veut dire chaque étape traduite librement en français:

  • Aperçus (Insights): Comprendre l’état actuel des choses dans l’organisation. Pour collecter cette information, il y a plusieurs méthodes et outils tels que : sondages, entretiens, rétrospectives, etc. Une fois toutes ces informations recueillies, il faut les analyser dans sa vue globale et voir les options à essayer.
  • Options: Les options à mettre en action ont toutes un coût, une valeur et un impact. Prendre celles qui font le plus de sens dans le contexte actuel afin de valider les hypothèses émises.
  • Expérimentations: Introduire un changement via une option et voir comment il en résulte. Cette étape a aussi le sous-cycle suivant :
    • Préparation: Préparer à valider nos hypothèses et notre approche avec les personnes affectées par le changement.
    • Introduction : Le changement est introduit dans le processus.
    • Révision : On regarde les résultats après un certain temps. Selon ce qui s’est passé, on peut prévoir un autre cycle d’expérimentation.

Dans les premiers chapitres du livre, on introduit rapidement le cycle et ses origines. Pour le reste du livre, on décrit en détails chacune des étapes du cycle avec, bien entendu, les commentaires et l’expérience vécue de l’auteur. Ce qui en fait un livre captivant et intéressant à lire. Lors de sa lecture, il nous arrive de prendre note de plusieurs éléments et conseils qui pourront nous servir en tant que coach Agile. Tout ceci est valable autant pour des changements de processus que pour l’adoption de nouvelles techniques telles que le TDD. Un « must » donc à lire pour tout coach Agile impliqué dans une transformation Agile.

En résumé, voici mes trois leçons apprises suite à cette lecture:

  • Utiliser un cycle basé sur le feedback pour mesurer le changement.
  • Impliquer les gens affectés par le changement dans la conception du changement.
  • Bien mesurer nos options. Chacune d’entre elles a un coût, une valeur et des impacts.

Références :

Mon mindmap coach Agile

Suite à une commande de mon patron, j’ai monté un mind map du coach Agile. Contrairement au rôle de Scrum Master clairement défini dans le guide Scrum, la description du coach Agile n’est pas standardisée à mon avis. Il y a tout de même les belles initiatives du Agile Coaching Institute et de ICAgile pour leurs efforts à définir les niveaux de coach Agile ainsi que les objectifs d’apprentissage requis à chaque niveau.

De mon côté, je voulais partager le résultat de cet exercice. C’est mon job après tout alors je devrais être capable d’énumérer quelques-unes de mes responsabilités.

CoachAgile_Mindmap

J’ai regroupé les Post-It par thème (formateur, facilitateur, mentor, coach et savoir-être). Ma première constatation fût que les thèmes coach et savoir-être étaient les plus forts. Cela fait du sens à mon avis puisque ce sont souvent ces compétences que j’utilise dans mon travail. Néanmoins, je fais appel à des postures de formateur, faciltateur et mentor au courant de ma journée bien que ces postures soient moins présentes.

Selon vous, quels seraient les Post-It à rajouter à mon mind map papier?

Références

Formation exclusive à Québec

Vous avez travaillé sur des projets Agiles, très souvent, en prenant une approche Scrum ou Kanban, et pour la plupart du temps, vous avez eu des expériences positives. Mais vous avez aussi sans doute rencontré quelques défis, spécialement si vous évoluez dans un contexte de grande entreprise.

C’est justement pour vous aider à faire face à ces défis que l’approche de livraison Agile disciplinée(DAD) a été conçue. DAD est une approche Agile hybride qui combine diverses stratégies à partir d’une variété de sources telle Scrum, XP, Agile Modeling, Kanban, SAFe et beaucoup d’autres. DAD se présente donc comme une approche pragmatique qui reflète la réalité des environnements des entreprises d’aujourd’hui fournissant des orientations cohérentes pour vous aider à répondre à bon nombre, sinon la totalité, des défis auxquels vous faites face.

Le Centre d’Excellence Agile de Facilité Informatique est fier de présenter l’approche de livraison DAD pour la première à Québec. En effet, le 9 décembre prochain, Scott Ambler, co-fondateur de DAD, sera à Québec pour donner cette formation. Pendant une journée, venez travailler avec Scott pour vous aider à répondre aux questions suivantes:

  • Comment se positionnent les activités d’architecture dans tout ça?
  • Comment pouvez-vous rester Agile quand vous avez besoin de donner une estimation fixe dès le démarrage du projet?
  • Comment peut-on travailler d’une manière Agile lorsque l’équipe n’est pas dédiée et/ou co-localisée?
  • Comment fait-on pour structurer les grandes équipes Agiles?
  • Comment pouvons-nous améliorer nos stratégies d’assurance qualité?
  • Comment pouvons-nous évoluer de Scrum vers DAD?
  • Comment se positionne le DevOps à l’intérieur de DAD?
  • Qu’en est-il des corps de métiers plus traditionnels tels que les gestionnaires de projet / analystes d’affaires / professionnels de la qualité?

Inscrivez-vous dès maintenant pendant qu’il reste encore quelques places de disponibles!

La rétrospective positive

Selon le guide Scrum, la rétrospective de sprint est « une occasion pour l’Équipe Scrum de s’inspecter et de créer un plan d’amélioration qui sera mis en place au cours du Sprint suivant. »

Au début de ma carrière de Scrum Master, je suivais cette définition assez rigoureusement. Cette rencontre était employée pour identifier nos problèmes et les régler. Cependant, en progressant dans ce rôle, j’ai remarqué que les gens devenaient fatigués d’être constamment mis au défi pour trouver des pistes d’amélioration. En creusant de plus en plus, on rencontrait des problèmes organisationnels ou professionnels qui ne pouvaient tout simplement pas être résolus. Cela minait l’humeur des gens. Curieusement, lorsque les commentaires restaient positifs à la rétrospective, l’équipe se dressait plus facilement un plan d’actions. Lorsque les gens se sentaient bien et fier d’eux-mêmes, ils travaillent plutôt à s’améliorer davantage.

J’ai aussi découvert que les rétrospectives positives se déroulaient mieux lorsqu’on utilisait un artéfact pour démarrer les conversations. Simplement démarrer la rétrospective en demandant aux participants de parler des aspects positifs du sprint était bizarre. Il fallait mettre la table, voir casser la glace.

Pour orienter les conversations positives, j’utilise habituellement deux outils: le calendrier niko-niko et le mood board. Le calendrier niko-niko est un outil bien documenté où on demande à chaque membre de l’équipe d’inscrire son état d’esprit général à chaque jour du sprint. On peut alors effectuer une rétrospective sur le niveau de bonheur de l’équipe à la fin du sprint.

Dans l’éventualité où un tel outil n’a pas été mis en place, je considère le mood board comme étant une bonne alternative pour démarrer des conversations positives. En somme, le mood board est un graphique où l’axe des X est la ligne du temps et l’axe des Y est le niveau de bonheur à travers le temps. Puisque ceci est un outil très scientifique, on peut remarquer que le niveau de bonheur maximal est le gros bonhomme Sourire dans la photo qui suit:

RetrospectiveMoodBoard

Il y a aussi des couleurs différentes pour illuster le parcours de chaque membre de l’équipe. Lors de ce projet, nous avons substitué plusieurs joueurs, d’où le début des courbes à différents moments. Une fois leurs courbes tracées, je demande aux participants dans la salle d’identifier des moments positifs en lien avec cet artéfact.

Dans la photo ci-haut, on remarque que le niveau de bonheur est à son plus bas aux itérations 5 et 6. Bien qu’on aurait pu s’enlisser dans les raisons qui nous amenées là, l’objectif de la rencontre était de rester positif. Les membres de l’équipe se sont donc mis à parler d’événements positifs qui les ont fait passer à travers cette période. Jean-Sébastien (ligne verte) a parlé de la venue positive de Martin #2 (ligne mauve). Et les conversations ont continué à être positives pour le reste de la rencontre.

Au final, aucun plan d’actions tangible n’est sorti de cette rencontre. Seulement de bonnes appréciations envers les membres de l’équipe. Et des fois, la reconnaissance par les pairs est ce qu’il faut discuter lors de la rétrospective d’équipe.