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

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.

Ce que l’on a retenu de l’Agile Tour Québec 2015

Comme chaque année, l’Agile Tour Québec est une journée spéciale. En plus de formations et conférences, c’est une belle occasion d’avoir des échanges intéressants et de renouer avec d’anciens et de nouveaux collègues. Voici donc les faits saillants que nous avons retenus de cette journée:
Conférence Principale
L’expert de l’Agilité disciplinée, Scott Ambler, était de passage en tant que conférencier principal. Il a bien sûr discuté sur son approche, DAD, surtout au niveau entreprise.
  • On ne peut se limiter qu’à Scrum. On doit s’élever davantage, notamment  au niveau de l’entreprise.
  • Afin de s’élever, il faut avoir une pensée tactique et stratégique.
  • Comment réagiriez-vous si Google essayait de prendre votre business ?
  • Chaque {personne, équipe, organisme} est unique. On ne peut donc appliquer la même recette à tous.
  • Même chose pour les « lifecycle » de nos systèmes informatiques, un format ne convient pas à tous.
  • Bon conseil: toujours faire les choses les plus risquées en premier.
  • Important: l’équipe doit être au courant de la vision d’entreprise.

[slideshare id=54900825&doc=disciplinedagileenterprise-151109100627-lva1-app6892&w=650&h=500]

Lean/Kanban/Kaizen
Le lean est toujours présent à l’Agile Tour sous une forme ou l’autre. Comme par exemple:
Kaizen ou amélioration continue:
  • Petits changements simples que l’on peut contrôler 
  • Pas une responsabilité du gestionnaire, mais plutôt celle des équipes; le gestionnaire encourage cette responsabilité et la catalyse.
  • Ludifier une initiative d’amélioration continue permet de mobiliser les gens.
  • Il faut impliquer les équipes dans la ludification en leur faisant définir les règles et le système de récompense.

 

User Expérience (UX)
Le UX avait une bonne présence cette année avec 2 conférences. Voici en gros ce que l’on a retenu:
  • Le UX, c’est une forme de mentalité dans le processus de développement
  • La recherche se veut :
    • Efficace
    • Efficiente
    • Satisfaisante
    • Compréhensible
  • Le UX est composé de plusieurs techniques qui se regroupent dans les thèmes suivants:
    • Prototypage
    • Analyse d’affaire
    • Design visuel
  • Aller voir les utilisateurs pour réaliser le bon produit afin d’obtenir une meilleure adoption
  • Important de récompenser les échecs, cela nous permet d’apprendre
  • 3 saveurs au UX: Traditionnel, Agile et Lean
  • Bref: L’expérience humaine prime avant tout !
Pratiques Techniques:
Plusieurs sujets divers parlant du coté technique tels que:
L’excellence technique:
    • Nous sommes dans l’ère de la créativité désormais. Sommes-nous prêts ?
      Pour soutenir cette créativité et rester compétitif, il faut être capable de s’adapter rapidement. Pour cela, il faut mettre la qualité du code en priorité.
    • La connaissance est maintenant partout et les choses se complexifient
    • Besoin d’avoir une main d’oeuvre passionnée et curieuse car nous tendons vers une société axée sur le logiciel
    • Les pratiques d’extrême programming sont un préalable à l’Agilité, le code doit être Agile pour être Agile. Scrum et XP sont complémentaires.
    • L’excellence ce n’est pas d’être parfait mais d’être passionné, curieux (il questionne et n’est jamais satisfait du statu quo..) et créatif.
    • Vaut mieux embaucher une personne excellente que 10 mauvaises, l’embauche est la chose la plus importante.
Processus de développement:

Innovmetric a implanté de nouvelles pratiques afin de pallier à ses problèmes qui ralentissaient le développement :

    • Implantation de l’Agilité afin de faciliter la communication dans le cadre du développement et le bon travail d’équipe
    • Des outils ont été implantés afin de :
      • Tester quotidiennement la performance en mesurant le temps d’exécution des fonctionnalités.
      • Détecter la mauvaise utilisation de pointeurs et références en C++.
      • Valider les dépendances entre les modules/projets qui ont été implantés.
      • Enregistrer la pile d’appels dans un fichier dès qu’une exception anormale a lieu.
    • Les tests unitaires automatisés et de simulation de clics, sont exécutés sur une grande variété de systèmes d’exploitation et sur des comptes utilisateurs Windows ayant des droits d’accès variés.
    • Se sont dotés d’une politique pour que 10% des tâches des sprints soient consacrées à l’amélioration continue du système, et 90% pour le développement standard de nouvelles fonctionnalités.
    • L’intégration continue permet de connaître facilement la cause d’un impact négatif sur les tests automatisés ou sur un écran utilisateur. Il suffit de voir quels fichiers ont été modifiés depuis la dernière compilation/exécution des tests et d’analyser le tout afin de connaître la cause du problème et le correctif requis.

Au final, ça rapporte d’implanter ces processus:

    • Les coûts de développement sont maintenant moins grands qu’au départ.
    • Les employés sont plus heureux compte tenu qu’ils travaillent en collaboration et dans un cadre d’amélioration continue.
    • L’embauche et la formation de ressources est plus facile, compte tenu que le système est entouré de processus clairs et fiables.

Bref, dans l’ensemble les conseillers de Facilité Informatique ont bien apprécié cette journée. On a déjà hâte d’être à l’an prochain pour découvrir de nouveaux sujets afin d’améliorer notre Agilité.

Gagnons nos matchs en équipe

Durant un match de hockey, un défenseur reçoit la rondelle alors qu’il est dans sa zone. Il n’y a que le gardien entre lui et le but adverse. Alors, il décide de patiner avec détermination. La foule est en liesse à la venue de ce nouveau point. Encouragé par les cris de la foule, notre défenseur patine de plus en plus vite, distançant ses adversaires. Et, à la ligne bleue, il s’arrête net et il regarde autour de lui. Un joueur adverse en profite pour lui voler la rondelle.

A la fin de la période, le coach de l’équipe rencontre son défenseur et lui demande :

  • « Pourquoi, n’as-tu pas tenté de scorer? ».
  • « Ben! C’est la job de l’offensive, moi je suis à la défense. C’est pourquoi je cherchais à faire une passe à un de mes collègues », lui répond le joueur.
  • « Attends, c’est quoi l’objectif de l’équipe » rétorque le coach
  • « Ben! De gagner coach. »
  • « Et pour gagner, que devons-nous faire? »
  • « Mettre la rondelle dans le but. »
  • « Nous sommes d’accord sur ce point. Alors la prochaine fois que feras-tu? » Lui demanda le coach.

J’ai trop souvent observé dans les équipes de développement, des joueurs restés campés dans leur rôle.

  •  « Ben! ce n’est pas à moi de le faire. »
  •  « Ce n’est pas moi l’analyste. Ce n’est pas moi le testeur. Etc. »
  •  « Il n’y a que lui qui sait comment faire. Moi, je ne touche pas à cela. »
  •  « On ne peut pas livrer, les testeurs n’ont pas terminé la validation. Alors, on travaille sur autre chose. »
  •  « L’analyse fonctionnelle n’est jamais prête à temps. Je dois attendre. »

Vous avez omis un de vos objectifs d’équipe, celui qui va faire que vous allez gagner. En tant que membre d’équipe, votre devoir c’est d’aider vos collègues à atteindre les objectifs fixés. Même si pour cela, je dois faire des tâches qui ne sont pas écrites dans ma description de tâche? Oui. Même si pour cela, je dois faire confiance à mes coéquipiers pour réaliser des tâches liées à mon rôle? Oui. Pensez-y. Dans une équipe de hockey, l’objectif de chaque joueur, c’est de marquer des buts. Alors oui, si un gardien de but se rend compte qu’il peut marquer, il va tenter le coup.

Alors, essayez ce qui suit : avant de commencer une nouvelle tâche regardez qui vous pouvez aider, lorsqu’un membre de votre équipe vous présentera un problème ou un bloquant, demandez-lui comment vous pouvez l’aider. Lorsqu’un membre de votre équipe dira : « C’est plate, je n’ai plus rien à faire. L’analyse fonctionnelle n’est pas prête. » Demande-lui : « Que peux-tu faire pour aider? Comment peux-tu collaborer, et ce, pour le bien commun de l’équipe? »

En tant que professionnel et membre d’équipe, au cours du dernier mois, combien de fois avez-vous saisi l’occasion de sortir de votre rôle pour le bien commun de l’équipe? Quelles sont les possibilités que cela ouvre maintenant?

Que pensez-vous de faire en sorte d’atteindre vos objectifs et de gagner vos matchs?

Introduction à l’Agilité Disciplinée (Disciplined Agile)

dad1Vous avez manqué l’introduction à l’Agilité Disciplinée qui a eu lieu à Agile Québec, mercredi le 28 novembre ou vous désirez revoir la présentation? Vous pouvez la revisionner à l’adresse suivante : https://prezi.com/ezhvhppqwh7f/introduction-a-lagilite-disciplinee/

De plus, vous trouverez ici-bas les différents mind map utilisés lors de la présentation, mais avec l’ensemble des techniques et stratégies proposées par DAD.

Lire la suite

Votre Agile est-elle disciplinée? Scott Ambler? DAD? Ça vous dit quelque chose?

Vous avez travaillé sur des projets Agiles, très souvent, en prenant une approche Scrum ou Kanban, et pour la plupart, 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 telles 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.

Nous profiterons de la présence de Scott Ambler, conférencier principal de l’Agile Tour Québec 2015, pour en apprendre plus sur ce cadre de travail de plus en plus populaire et son application dans votre contexte organisationnel. Dans le but de compléter cette première rencontre, inscrivez-vous à la formation ‘’Au-delà de Scrum : L’approche de livraison Agile disciplinée (DAD) qui aura lieu le 9 décembre à Québec.

Ne tardez pas, les inscriptions sont limitées, réservez votre place maintenant : Formation DAD

Facilité Informatique est fière de mettre son excellence au service de la communauté Agile!

INSCRIPTION>>