Notes de lecture : Lean Change Management

Article publié précédemment sur ExcellenceAgile.com

leanchangemanagementNous 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 :

Être réviseur de livres techniques

Savez-vous qu’il possible de faire partie des réviseurs d’un livre technique en cours d’écriture ?

Cela vous demande un peu de temps et de donner un feedback constructif à l’auteur. Est-ce que vous avez besoin d’être un expert pour faire une revue de code ? Non, pas vraiment. Il faut surtout être intéressé par le sujet et bien gérer son temps. Il faut parfois respecter des dates cibles pour envoyer nos commentaires.

Les avantages ?

La maison d’édition vous donne en général une copie gratuite du livre et vous avez votre nom inscrit dans la liste des réviseurs quelque part dans le livre. Vous aurez aussi la satisfaction d’avoir aidé l’auteur à rédiger son livre. C’est quand même très bien.

Et peut-être aussi qu’ils choisiront une de vos citations et l’afficheront à l’arrière du livre. C’est que Manning Press a fait dernièrement pour le livre « BDD in action ». C’est assez flatteur, pour mon cas, de retrouver son nom et celui de son employeur à côté de Dan North, inventeur du BDD.

BDDInActionSi être un réviseur technique d’un livre vous intéresse, regardez les liens suivants:

Top 5 – Lectures 2012

J’ai fait plusieurs lectures en 2012 et sur des sujets diverses. Je vous propose ici une compilation Top 5 des meilleurs ouvrages liés au domaine de l’informatique que j’ai lu dans le courant de l’année 2012:

1. Software Architecture for Developers par Simon Brown

Excellent résumé de ce que fait (et devrait faire) un architecte logiciel et comment partager sa structure et sa vision à l’équipe. L’auteur, Simon Brown, nous montre son côté pragmatique dans cette vue d’ensemble. J’ai apprécié particulièrement les parties sur le rôle d’architecte et la façon de concevoir et de communiquer le logiciel.

On y parle aussi de l’agilité et de son impact sur l’architecture ainsi que la notion qu’un diagramme UML n’est pas toujours nécessaire. Noter que ce livre est publié de manière indépendante sur « Leanpub » et est toujours en évolution. Un « Must » à lire pour tout développeur ou un architecte logiciel!

Lien du livre sur LeanPub

 

2. Specification By Example par Gojko Adzic

Gojko Adzic nous a écrit un 2e livre sur les spécifications.  Son premier, Bridging the communication gap, était surtout de nature théorique. Cette fois-ci, on nous présente les expériences de personnes et organismes différents avec l’utilisation de la spécification par l’exemple. En plus de cela, nous voyons comment Gojko a fait évoluer sa pensée sur la spécification et après quelques chapitres, nous allons au-delà des notions de base.

Soit dit en passant, ce livre ne parle pas de code ou d’outils. Seulement des principes et des pratiques utilisées pour communiquer les spécifications dès le début d’un projet logiciel jusqu’à sa fin.
Un des beaux résultats de cette approche est que tout le monde dans une équipe de développement logiciel travaille à avoir une « Documentation vivante » au lieu d’un tas de papiers classés quelque part dans un classeur.

Je recommande cette lecture à toute personne impliquée dans la création de logiciels. En particulier si utilisez les approches suivantes:  Behaviour Drive Development (BDD), Acceptance Test-Driven Development (ATDD), Test-Driven Development (TDD) et le Domain Driven Design (DDD).

Liens commandités du livre sur Amazon : France | Canada | USA

 

3. Techical Blogging par Antonio Cangiano

Si vous êtes sérieux à propos des blogues, ce livre est pour vous. L’auteur, Antonio Cangiano, couvre de nombreux aspects liés à l’écriture de blogue tels que la planification, la création de contenu, la promotion, le référencement, les avantages et les médias sociaux. Certains aspects sont directement liés à l’outil de blogage WordPress, mais la plus grande partie du contenu de ce livre peut être appliqué à n’importe quel type de blogue.

Liens commandités du livre sur Amazon : France | Canada | USA

 

4. Steal like an Artist par Austin Kleon

L’auteur, Austin Kleon, nous donne 10 règles pour développer notre créativité. Ces règles peuvent être utiles à toute personne, artiste ou non. En fait, pourquoi voler comme un artiste ? Parce que rien n’est original finalement… Le livre est aussi magnifiquement illustré et le papier utilisé pour imprimer le livre est de grande qualité. Le résultat: un excellent livre sur la créativité et la productivité qui se lit très bien. Inspirant !

Liens commandités du livre sur Amazon : France | Canada | USA

 

5. Impact Mapping par Gojko Adzic

Un 2e livre de Gojko Adzic dans mon Top 5 (eh oui !). Celui-ci est un peu différent toutefois. En fait, il s’agit plutôt d’un guide qu’un d’un livre en soit. L’auteur nous présente une technique pour mieux comprendre, mesurer et aligner les objectifs de l’entreprise avec la planification de la livraison d’un produit logiciel. Voici le « Impact Mapping » qui est une sorte de schéma heuristique (ou « Mind Map ») pour représenter les aspects suivants: But (pourquoi), Acteur (qui), Impacts (comment) et  le Livrable (quoi). Aussi, le livre est magnifiquement illustré. Je recommande vivement d’obtenir la version papier.

Liens commandités du livre sur Amazon : France | Canada | USA

Agile Tour 2012: Des gens passionnés au rendez-vous

Nous étions plus de 400 participants, bénévoles, présentateurs et organisateurs à l’Agile Tour Québec 2012 cette année. 400 passionnés, curieux et avides d’information et d’échanges avec ses pairs.

Ce fut une belle journée et un plaisir de côtoyer tous ces gens pour cette 4e édition (!) pour la ville de Québec de cette journée de conférences consacrées au développement Agile.

(Cette photo a été prise par Isabelle Therrien, Coach Agile chez Agile Partnership)

J’ai bien aimé la conférence principale, ou « Keynote », de cette année à l’Agile Tour 2012. Le conférencier, Jonathan Rasmusson, nous a servi une plénière forte intéressante. Il nous a partagé son expérience avec les deux histoires suivantes:

« Who moved my Agile cheese ? / Qui a déplacé mon fromage Agile »

En s’inspirant un peu du livre « Who moved my cheese ? », Jonathan abordait le thème du changement. Même les gens « Agiles » peuvent être confrontés à celui-ci et parfois, l’agilité n’est pas toujours la solution. En écrivant son livre, Agile Samurai, il a tenté de le faire à la sauce Agile, en itérations, « User Stories » et autres artéfacts de l’agilité. Mais, ce qui a marché le mieux, c’est d’aller à son café de 6h00 à 8h00 et de travailler sur son livre avant de se rendre au travail. Il a du changé sa manière de faire « Agile » pour y aller d’une autre manière plus efficace pour lui. Pourquoi cela a marché ? Selon lui, c’était tellement une idée personnelle, que ce n’était pas pour lui vraiment du travail. Le travail avait arrêté d’être du travail est était devenu une forme d’art pour lui.

Le changement est un phénomène naturel et cela va nous arriver un jour ou l’autre. Même l’agilité risque changer dans les années à venir.

« Tests unitaires = Qualité. Vraiment ? »

JonRasmussonEst-ce que les tests unitaires sont les seules garanties de qualité ? En s’introduisant dans la communauté des développeurs d’applications avec iOS, Jonathan a découvert que les tests unitaires et l’intégration continue n’étaient pas pratiqués régulièrement. Seul le « refactoring » semble être présent. Pourtant, la qualité du travail était au rendez-vous, et ce, sans tests unitaires… Comment est-ce possible ? L’attention et le souci du détail de Apple dans ses produits ainsi que sa communauté de développeurs attentionnés y est pour quelque chose selon lui.

Bien qu’il croit toujours à l’importance des tests unitaires dans certains contextes, un autre aspect vient influencer davantage la qualité: La passion et l’attention des « artisans » à faire le meilleur produit qui soit.  Bref, la qualité est plus que des tests unitaires (mais ces derniers sont toujours très important). Il a mentionné aussi quelque chose d’intéressant. La communauté Agile et la communauté des développeurs de logiciels Apple (ou iOS) pourraient s’échanger un truc ou deux pour que chacun s’améliore.

En conclusion, c’était moins flamboyant que l’an passé avec Robert C. Martin, mais la conférence m’a touchée davantage. C’est bien beau parfois d’avoir des gourous qui nous montre leur savoir et la bonne manière de faire les choses, mais c’est bien aussi de faire changement dans le type de présentation. Jonathan nous a plutôt ramené à la base en nous parlant de ses récentes expériences professionnelles. Et je résume cette base à retenir de cette manière:

Avoir des gens passionnés et qui veulent prendre soin de leur travail, c’est un pas de plus pour obtenir un résultat de qualité. On peut apprendre toute sorte de notions sur l’agilité à pratiquement n’importe qui. Mais on ne peut pas leur apprendre à prendre soin de leur travail.

Références :

Comment se déroulent vos revues de code ?

En lisant l’excellent article « What should a good code review look and feel like? » de l’auteur Roy Osherove, j’ai fait une réflexion sur la manière dont j’effectue des revues de code.

 Mon côté « Exteme Programming (XP) » irait de manière pragmatique avec seulement de la programmation en paire, ou « Pair Programming » pour la revue de code. Par contre, dans mon entreprise qui est dans le domaine de la finance, des audits de vérifications de qualité sont nécessaires. Donc, nous utilisons régulièrement une liste de vérifications de conformité que les programmeurs et analystes organiques remplissent lors de la revue de code.

Bien que ceci officialise cette validation, ce n’est pas complet comme exercice selon moi. J’aime bien, en plus de compléter notre liste de vérification, m’assoir quelques minutes avec le programmeur et regarder le code ensemble. Surtout si on parle d’un développement d’un nouveau composant. C’est plus « humain » et je constate qu’il se produit alors un meilleur transfert de connaissance et qu’il s’en suit de bonnes discussions au sujet de code.

Je me demande un peu comment ailleurs on procède lors d’une revue de code, en particulier dans les entreprises où la preuve de la vérification de la qualité du logiciel est requise. Des exemples  ?

Référence:

Est-ce que vous tenez à votre équipe ?

J’ai assisté mercredi soir dernier à la conférence de François Beauregard intitulé « De l’individu à l’organisation en passant par l’équipe« . C’était dans le cadre des conférences mensuelles organisées par Agile Québec.

J’ai été particulièrement interpellé lors du sujet de la structure d’équipe. François a cité ceci (sans les mots exacts toutefois):

Il arrive parfois qu’on saborde les bonnes équipes à la fin des projets. C’est comme si au hockey, on prenait l’équipe qui a gagné la coupe Stanley, et on la divisait en donnant un joueur à chaque autre équipe.

J’ai vécu cela souvent dans le passé lorsque j’étais consultant et je le vois malheureusement encore dans mon travail actuel en tant qu’employé permanent dans une entreprise privé.

Je me rappelle, lors d’un de mes anciens projets il y a quelques années, que l’on avait une des meilleures équipes. Elle était d’ailleurs qui était composé ainsi:

  • 3 Programmeurs
  • 1 Analyste fonctionnelle
  • 1 Architecte Logiciel /  Scrum Master
  • 1 Chargé de projet

Au besoin, on pouvait avoir accès à d’autres personnes pour nous aider dans un aspect où l’on était moins expérimenté. Par exemple avec les bases de données, on se débrouillait bien. Mais, si on avait quelque chose de plus corés à faire, on pouvait avoir accès à un DBA pour nous aider. Notre équipe se complétait bien ainsi.

Après plusieurs sprints où l’équipe a vécu des hauts et des bas, des rétrospectives, des apprentissages, des démos aux clients, l’équipe était rendue très unie et pouvait pratiquement affronter n’importe quel défi selon moi. Elle était devenue un peu comme une « super-équipe ». Mais le projet fut terminé, les personnes séparées dans différents projets selon les affectations et avec pour résultat: plus de super-équipe !

Je suis certain que si on avait fait des efforts pour la garder intacte et la déplacer de mandat ou de client, elle aurait été très performante, car plusieurs aspects étaient maintenant acquis. Les gens se connaissent bien, il y avait une chimie qui s’était créée. Mais pourquoi on ne veut pas tenir à ce genre d’équipe au sein de certaines entreprises ?

Je travaille maintenant pour une entreprise privée et je vis parfois la même chose. Avec le mélange de personnels permanents et de consultants, dont les contrats qui se termine à différents moments, c’est une belle jonglerie que de garder une bonne équipe intacte.

Comment régler ce problème ?

Je ne crois pas au « responsable unique » en général dans la vie et c’est le cas ici je crois. Les gestionnaires et directeurs ont des contraintes de budget et de ressources à gérer. Ils font de leur mieux en dépit des circonstances. Toutefois, si ce n’est pas le cas, ils ont peut-être à se à se rapprocher des équipes de temps en temps pour mieux comprendre ce qui se passe.

Du côté des équipes de projets, il faut qu’ils sensibilisent les gestionnaires au fait que l’équipe est très bien comme cela et qu’il faut la garder intacte autant que possible.

En bref, le facteur humain étant ce qu’il est, il ne doit pas être géré comme une ressource, mais plutôt de manière organique. J’aime bien la métaphore que Francçois Beauregard a utilisée pour illustré ceci:

La gestion d’une équipe, c’est comme faire grandir un beau jardin.

Ceux qui vivent parfois cette problématique, est-ce que vous voyez d’autres solutions ? N’hésitez-pas à laisser vos commentaires sur ce billet.

Références :

Agile Tour 2011: Un beau défi réalisé !

IMG_0282

Pour une troisième année consécutive, l’Agile Tour était de retour à Québec mercredi dernier, le 26 octobre. Je m’étonne toujours de la qualité du travail que l’on peut faire pour organiser cette conférence en dépit des circonstances. Par exemple, le fait que personne ne travaille à temps plein là-dessus. Tous les organisateurs ont déjà un premier travail.

Aussi, cette année c’est un peu spécial, car un de mes auteurs préférés de livre, Robert “Uncle Bob” C. Martin, était notre conférencier principal.

J’ai adoré sa présentation, “Clean Architecture”, qui était instructive et divertissante, comme d’habitude dans son cas.

En passant, voici les nouveautés que nous avons amenées cette année:

  • La conférence a lieu dans un hôtel au lieu de l’université Laval
  • Nous avons quatre de salles de conférences + une grande salle pour la conférence principale et les repas.
  • Les conférences sont divisées par thème et par salle afin d’en avoir pour tous les goûts chez nos participants.
  • Un comité de programme a été établi afin d’évaluer et de choisir les soumissions de conférences.
  • 18 sessions différentes, en plus de la conférence principale, étaient offertes aux participants.

Aussi, en tant qu’OSBL (organisme sans buts lucratifs), nous nous efforçons de rendre accessible cet événement au plus grand nombre possible de personnes. Nous avons eu aussi un nombre record de participants (400) et nous avons dû en refuser plusieurs pour cause de logistiques et d’espace dans les salles. L’engouement pour le développement Agile est vraiment en hausse à Québec cette année !

Certaines petites choses sont encore à améliorer, mais ce fut selon moi un très bon événement de grande qualité et pour un prix modique (50$). Ce qui concorde parfaitement avec la mission de la communauté Agile de Québec.

Un gros merci particulier à mes collègues pour qui la plupart c’était la première fois qu’ils organisaient un « Agile Tour » :

  • David Beaumier
  • Félix-Antoine Bourbonnais
  • Patrice Caron
  • Louis-Joseph Foujieu
  • Dave Jacques
  • Amélie Turgeon

Au plaisir de vous retrouver à l’Agile Tour 2012 !