Auteur : Karl Metivier

Idées, pensées et autres errances d'un architecte logiciel et practicien agile.

Small Basic, un bel outil d’apprentissage

En bon papa, je voulais initier ma grande fille à la programmation et aussi lui expliquer un peu ce que je fais dans la vie.

En regardant l’environnement de développement Small Basic de Microsoft, qui est gratuit en passant, j’ai donc décidé de l’utiliser et de regarder un peu ce qu’il peut faire.

Premièrement, l’interface est très « bonbon » avec seulement quelques gros boutons. Beaucoup plus épuré que Visual Studio:

image

Par la suite, je remarque que l’intellisense est aussi très graphique:

image

J’aime bien.  Je trouve que cela rend facile de voir les possibilités du langage. Je regarde aussi dans la documentation pour me trouver quelques exemples intéressants et je tombe sur les commandes suivantes:

image

Eh oui, le langage “Logo” est inclus en partie dans le Small Basic avec la commande “Turtle”. Ce fut un de mes premiers langages de programmation sur mon vieux Commodore 64 il y a de ça de nombreuses années. D’ailleurs, cela ressemblait à ceci à l’époque:

c64-terrapin-logo-vers-a.jpg

Par la suite, je guide ma fille pour l’aider à écrire ses premières lignes de code et on y va avec la compilation:

image

Ce qui donne un petit déplacement de la tortue:

image

On a aussi repris un exemple de la documentation qui fait tourner la tortue pour faire un beau dessin. Voici le code:

image

Et son résultat:

image

Cool, n’est-ce pas  ?

D’ailleurs la documentation est assez bien faite et montre différents exemples. On peut aussi compiler le tout et faire des exécutables.  Avec cela, s’achève cette première leçon, elle préfère jouer sur l’ordinateur que de programmer semble-t-il… On va donc la laisser grandir un peu plus et on essayera une autre fois.

Références:

Publicité

Atelier Gestion Visuelle

clip_image002

Aujourd’hui, lors de l’Agile Tour Québec 2010, j’ai eu l’occasion d’animer un atelier sur la gestion visuelle. Le tout s’est bien déroulé malgré le temps plus restreint (1 heure) pour mener l’activité.

La participation de tous fut excellente et une bonne créativité en est ressorti dans le tableau des tâches de tous et chacun. Bravo !

J’avais aussi mentionné que je publierais sur mon blogue les ressources en questions mentionnées lors de la séance ainsi que les photos prises des tableaux.

Les voici :

Aussi, si vous voulez discuter ou poser des questions au sujet de la gestion visuelle, juste à mentionner le hashtag #GestionVisuelleQc sur Twitter. J’y participerai avec joie aux discussions qui pourront y avoir lieu.

Merci encore à tous les participants de l’atelier et à ceux de l’Agile Tour Québec 2010 en général !

Critique du livre Agile Samurai

The Agile Samurai: How Agile Masters Deliver Great SoftwareUn autre livre sur l’agilité ?

Bon, il parle de quoi ce livre, une autre méthodologie ?

Une autre manière différente d’appliquer l’agilité ?

Non, rien de tout cela.

Ce magnifique petit livre (250 pages environ) ne fait que nous réexpliquer les différentes facettes de l’agilité mais d’une manière un peu spéciale.

Tout est présentement de manière simple, abondamment illustré et drôle par moment.

Voici la description des différentes sections du livre :

  • Dans la première partie du livre, on commence avec la base, soit l’Introduction à l’agilité et la description d’une équipe agile et les rôles que l’on y retrouvre normalement.
  • Dans la deuxième partie, Agile Project Inception, j’ai particulièrement apprécié la section sur le début d’un nouveau projet et les choses à faire afin que l’équipe s’approprie davantage le projet. On y explique diverses activités telles que le Inception Deck, un Elevator Pitch et la conception d’un Product Box. Je vais sûrement tenter d’essayer ces techniques un jour au l’autre.
  • La troisième partie, Planification d’un projet Agile, on discute de User Stories, Estimation et comment être flexible avec le Scope d’un projet.
  • La quatrième partie, Exécution d’un projet Agile, le concept d’itération prend tout son sens et on aborde plusieurs notions pour aider à livrer régulièrement notre produit logiciel. On voit comment les notions des 3 premiers chapitres fonctionnent ensemble. Exemples:
    • Comme quoi faire à l’itération 0
    • Quand faire l’analyse fonctionnelle
    • Communiquer l’information à l’équipe
    • Faire un espace de travail visuel
  • Pour finir, la dernière partie, Création d’un logiciel Agile, on fait la revue des pratiques d’ingénierie Agile connues et éprouvées tels que les tests unitaires, le refactoring, le TDD et l’Intégration continue. Même si je connaissais très bien ces notions, c’était intéressant de les trouver résumé dans le livre en y mentionnant de bons arguments pour les pratiquer.

Donc, on revoit la plupart des notions de l’agilité, ses principes et ses pratiques. Mais remis au goût du jour avec plusieurs illustrations et de nouvelles manières d’expliquer l’agilité. Le livre est raconté de la manière étudiant-professeur (ou plutôt Maître Sensei et Aspirant Guerrier pour rester avec la thématique Samurai) afin de nous glisser de prodigieux conseils tout au long du livre. On sent que l’auteur, Jonathan Rasmusson, a fait plusieurs projets agiles et veux nous communiquer son savoir et ses trucs. Bref, on trouve ici un guide visuel sur l’agilité, rien de moins. Même si vous être expérimenté avec l’agilité, vous avez de quoi à apprendre que ce soit les conseils du maître Sensei ou certaines techniques moins couvertes ailleurs.

Certaines notions ne sont abordés qu’en surface, tels que les Users Stories et le Refactoring,  et pour bien les maîtriser, il faudra peut-être faire d’autre lectures.

Petit point à améliorer selon moi dans le chapitre 2 sur l’équipe Agile. Le rôle « Programmeur Agile » couvre un peu trop large. On aurait dû le diviser avec un autre rôle plus senior genre « Tech Lead » ou « Agile Architect ». C’est certain qu’à la base on veut effacer un peu les rôles traditionnels et rendre l’équipe multifonctionnelle. Sauf que cela prend quelqu’un qui se charge en autre du respect des normes, de coacher l’équipe, de faire le lien avec les autres systèmes de l’entreprise et d’avoir une vue globale de l’architecture.

Merci en passant Pragmatic Press de m’avoir donné une copie ebook du livre en version beta et finale afin que j’en fasse la revue.

Darts

Mes points clefs:

  • Avant de commencer un projet Agile, il a des activités à ne pas oublier
  • Toujours avoir en tête les principes du manifeste agile et comment les appliquer concrètement
  • Scrum et XP Programming y sont mélangés pour ne faire qu’un dans le livre.

Les références:

TFS est ouvert aux vieilles technos

Je regardais récemment le scénario d’intégrer du code VB6 dans le gestionnaire de code source Team Foundation Server (TFS) 2008, histoire de faire un premier pas vers une conversion à .NET. C’est en fouinant un peu que j’ai découvert l’existence du Visual Studio Team System 2008 Team Foundation Server MSSCCI Provider

Ce petit provider de Microsoft s’avère très utile si vous avez de vielles applications et que vous voulez tout regrouper sous un même toit, comme avec TFS. On peut ainsi dire un beau bye-bye à Visual SourceSafe.

L’outil permet d’utiliser TFS comme gestionnaire de code source pour des outils de développement un peu vieillot tel que VB6 ou  Visual FoxPro. Il marche même avec PL/SQL après l’ajout d’un petit plug-in:

Du côté de VB6, tout marche très bien et les menus; ils sont pratiquement les même qu’avec Visual Source Safe (VSS):


On peut aussi changer de gestionnaire de code source au besoin grâce au programme suivant qui est installé avec le provider:

Une fois notre option choisie, on verra le bon gestionnaire de code source à la prochaine ouverture de notre outil de développement.

On peut donc ouvrir un projet VB6 sous VSS, changer le gestionnaire de code source et ouvrir une deuxième instance de VB6 qui utilisera TFS.

Points à retenir:

  • L’historique de VSS ne se copie pas dans TFS. À moins de faire une conversion, mais la procédure semble plus complexe qu’une simple copie des fichiers.
  • Le concept de fichiers partagés de VSS n’existe pas dans TFS. Si c’est utilisé, prévoir du temps pour réarranger le code.
  • La recherche dans TFS 2008 ne peut aller jusqu’au contenu des fichiers. On ne peut que chercher les titres des fichiers (!). Je ne sais pas si cette lacune est corrigée dans TFS2010 par contre.

Donc, ne jeter pas VSS aux poubelles trop vite. Il pourrait servir pour des recherches et des consultations de l’historique.

Mes prochaines lectures 2010

IMG_2447Avec les vacances, je prévois avoir davantage de temps libre pour faire de la lecture. On verra bien si cela va se réaliser ou non.

Histoire d’être mieux organiser, j’ai décidé d’aligner mes prochaines lectures afin de mieux suivre mes objectifs 2010. Je vais tenter d’en lire un ou deux pendant mes vacances et le reste, idéalement d’ici la fin de l’année.

Je vais aussi vous faire un résumé ici de ces prochaines lectures.

J’ai aussi terminés la lecture de plusieurs livres (Linchpin, Brain Rules, The art of Unit Testing) qui seront résumé aussi lorsque le temps me le permettra.

Bon, voici donc cette liste de mes prochaines lectures:

  • Made to Stick par Chip Heath & Dan Heath : Livre abordant la créativité et le pourquoi certaines idées “collent” davantage que d’autres. C’est une des suggestions de Mark Levison lors de son passage à Québec en mai dernier.
  • The Back of the Napkin et Unfolding the Napkin by Dan Roam: Pour en apprendre davantage avec le “Visual Thinking”. Dan Roam a écrit deux livres sur le sujet de comment illustrer ses idées de manière simple. Le premier de ces livres, The back of the Napkin, parle surtout de la théorie, et son deuxième, unfolding the napkin, est plutôt un guide de comment apprendre la technique par des exercices. Je me demande par lequel je vais commencer… La théorie ou la pratique ?
  • Simplicity par Edward de Bono: Ce livre vient d’être rééditer; il était auparavant difficile à trouver. J’ai déjà lu sur la simplicité avec le livre “Laws of Simplicity” et j’avais bien aimé. Daniel Lafrenière m’a recommandé celui de Edward de Bono pour approfondir davantage le concept de la simplicité qui peut s’utiliser un peu partout.
  • Presentation Zen par Garr Reynolds: Beau livre en couleur avec plein d’exemples de comment faire de bonnes présentations. Cela devrait bien accompagner le concept de Beyond Bullets points que je connais déjà bien.
  • Agile Coaching par Rachel Davies et Liz Sedley: J’ai ce livre depuis près d’un an et je ne l’ai pas encore lu. Il est grand temps que je m’y mettre donc. On y retrouve plusieurs bons conseils sur le coaching et comment introduire des nouvelles notions, comme l’agilité, au sein d’un équipe.
  • Programming F# par Chris Smith: Je voulais apprendre au moins un nouveau langage de programmation cette année. Ainsi avec le F#, je vais toucher le concept de la programmation fonctionnelle et aussi voir les nouveautés avec Visual Studio 2010.

Aussi, j’ai pris l’habitude de mettre les références à la fin de mes billets plutôt que répartis un peu partout dans le texte. Je trouve que cela rend le tout plus lisible. Qu’en pensez-vous ?

Références :

Scrum vs Scrum

Dans le coin droit, la ScrumAlliance et dans le coin gauche, la Scrum.org.

L’enjeu premier: La certification

Je trouve un peu déplorable ce qui se passe avec ces deux organisations dévouées à promouvoir l’approche Scrum. L’an passé, Ken Schwaber, fondateur de Scrum, quitte l’organisation qu’il a créée, la Scrum Alliance, pour des différents avec les autres organisateurs.

La raison de cette séparation ? Ken Schwaber mentionnait il n’y a pas très longtemps dans un webcast que la Scrum Alliance ne s’est pas bien comporté, tel un mauvais garnement, et s’est un peu égaré en devenant une entreprise voulant faire des profits.

Il fonde alors la Scrum.org et y propose aussi des cours certifiés pour de bonnes sommes d’argent. Bon, jusque là, on peu trouver cela un peu bonnet blanc et blanc bonnet malgré ce qu’en pense Ken Schwaber.

Pour les professionnels œuvrant dans le domaine de l’agilité, c’est un peu embêtant. Ceux qui détiennent déjà une certification avec la Scrum Alliance, comme moi, se demande s’il faut aussi aller chercher les nouvelles certifications de Scrum.org.

La compagnie Pyxis, dont les formations agiles sont une de leurs activités principales, n’ont pas trop le choix et offre les deux types de certifications.

D’une manière générale, on peut aussi se poser la question à savoir si les certifications en valent vraiment la peine ? Bob Martin a écrit un bon article là-dessus ici en questionnant la valeur d’une certification et son influence lors de l’embauche. À lire ici:

Pour moi, je trouve que la certification est un atout, sans plus. Cela prouve que l’on a soit :

  • Assisté à un cours (pour la certification ScrumMaster entre autre)
  • Passé un examen ou un questionnaire d’admissibilité

Il peut y avoir des tas de bonnes personnes avec des certifications et d’autres qui, bien que certifiés, sont moins compétentes.

Mais ce qui est le plus intéressant, n’est pas vraiment tout cette histoire de certification. Regardons de plus près un autre aspect qui est commun chez ces deux organisations:

  • Scrum Alliance: elle prépare une série de cours pour certifier des développeurs Scrum en y incluant les aspects d’ingénierie agile aux notions de Scrum.
  • Scrum.Org: Les premiers cours de Scrum Professionnal Developer sont déjà offert. Avec une alliance avec Microsoft, un cours de 5 jours a été développé pour faire la simulation d’un développement Agile de A à Z avec la nouvelle version de Visual Studio Team System 2010. Seront aussi inclus les notions du XP Programming dans le cours. On mentionne aussi qu’il y aura une version Java pour plus tard.

Ces deux formations semble des plus intéressantes de part leur contenu et la manière de les enseigner. 

Est-ce que vous remarquez quelque chose ? Moi je vois ici que les deux font la même chose et sont en train d’annexer le XP Programming à Scrum. On fait souvent mention effectivement que Scrum ne mentionne aucune technique d’ingénierie agile et qu’il est de bonne pratiques d’inclure des aspects du XP Programming au Scrum. Bob Martin y est même allé de la citation suivante:

XP + SCRUM = XP. SCRUM is a perfect subset of XP that wants to become XP.

Tandis que Ken Schwaber mentionne, dans le même webcast mentionné plus tôt, que XP est en train de disparaître malheureusement et que Scrum est un des seul processus les mieux définis.

Bref, au lieu de promouvoir l’agilité sous une seule bannière, on est divisé par cette petite guerre. Pourtant, le fait d’inclure les pratiques du XP Programming est en soi une évolution normale et souhaité selon moi. Mais de là à vouloir faire disparaître le XP Programming…

Qu’en pensez-vous ?

 

Références pour ce billet:

Critique du livre Pragmatic Thinking & Learning

J’ai lu le livre « Pragmatic Thinking and Learning: Refactor your Wetware » l’été passé (et oui, je suis un peu en retard dans mes critiques de livres, mais bon) et j’ai vraiment aimé ce petit livre. Son auteur, Andy Hunt, est aussi le co-auteur du fameux The Pragmatic Programmer . Le livre est bien présenté avec plusieurs chapitres, plusieurs images sont présentes pour illustrer certains concepts et on retrouve des capsules conseils un peu partout dans le livre.

Ce livre ne parle ni de programmation ni d’agilité (et oui !). On y discute principalement comment notre cerveau fonctionne et comment l’optimiser dans ce monde qui ne cesse d’évoluer et où nous sommes en apprentissage continue. Ce livre vise donc en particulier les personnes œuvrant dans le domaine informatique, mais pourrait aussi bien être très utile en générale pour quiconque.

Le livre commence en introduction en nous rappelant de toujours considéré le contexte car tout, d’une certaine manière, est inter relié. J’aime beaucoup aussi quand on décrit brièvement tous les chapitres du livre dans l’introduction. Cela nous permet d’avoir un bon aperçu du livre et voir ce qui va s’en venir. Autres sujets couverts dans les chapitres suivants : le modèle d’acquisition de connaissance Dreyfus, le fonctionnement de notre cerveau, comment apprendre délibérément, comment déboguer notre cerveau, acquérir de l’expérience et garder le focus.

J’ai particulièrement apprécié le chapitre 3 qui décrit comment fonctionne notre cerveau avec quelques analogies informatique. On y parle aussi de nos deux cotés du cerveau qui y sont rebaptisé mode linéaire (gauche) et mode riche (droit). L’idée n’est pas de connaître son côté dominant et de l’exploiter au maximum. Au contraire, nous avons besoins de deux côtés et il faut parfois se servir de l’un et l’autre pour arriver à nos fins. Par exemple, on peut partir quelque chose en mode riche (coté droit) pour générer des idées ou être créatif et par la suite retomber en mode linéaire (côté gauche) pour analyser le tout et faire des regroupements. Par contre, embarquer en mode riche n’est pas toujours évident, mais le livre mentionne plusieurs trucs et façons de faire pour y parvenir.

Un petit passage que j’ai bien aimé : Savez-vous que travaillez dans un cubicule détruit nos neurones ? La création de nouveaux neurones est davantage stimulée dans un environnement riche ou l’on peut observer, apprendre et interagir. Comme un animal dans une cage, un programmeur pris dans un cubicule ne fera pas la création de nouveaux neurones. Voilà pourquoi c’est important d’avoir un espace de travail ouvert et qui stimule nos sens. Voici quelques articles en référence à ce sujet :

Bref, j’ai beaucoup aimé ce livre et je le recommande à tous. Seul petit point négatif, certain sujets sont abordés très légèrement et aurait mérité qu’on y aille en profondeur. Pour ce, il faut donc me falloir d’autres lectures…

Mes points clefs : Darts

  • Nous avons besoin toujours besoin de nos deux modes de fonctionnement de notre cerveau : mode linéaire et mode riche.
  • Prendre en note chaque idée que nous avons. De cette manière on pourra en générer davantage
  • Lire et relire pour ne pas oublier. Utiliser des « mind maps » pour résumé le contenu.
  • Et ne jamais oublier le contexte, car tout est inter relié

Pourquoi je n’aime pas les générateurs de code ?

639165_old_factory

Je n’ai jamais vraiment beaucoup aimé les générateurs de code.

Vous savez, le genre d’outils qui peut vous générer des centaines et parfois même des milliers de lignes de code avec simplement quelques paramètres ?

Dans cet article, je vais discuter des points positifs et négatifs quant à l’utilisation d’outils de générateurs de code. Des exemples de différents générateurs seront aussi décrits.

On mentionne  souvent que ces outils nous font économiser des centaines d’heures et aide à avoir du code plus standard, je pense par contre qu’à moyen et long terme, il peut y avoir certains effets négatifs.

Comme par exemple :

  • Nuit à l’apprentissage: C’est le point le plus important d’après moi. Le simple fait que de ne pas avoir touché à une partie du code, nous rend vulnérable par rapport celle-ci. Aussi, il est important de bien comprendre un système informatique dans son ensemble et non seulement les parties du code qui n’ont pas été générées. Faut aussi savoir que tel générateur ne sera pas disponible dans un autre projet… Exemple: un générateur de code se charge de produire les contrats de services et de données en WCF. Il se charge de bien créer les classes et de mettre les bons « tags » relatifs à WCF. Dans ce cas, on ne peut pas dire que nous avons gagné de l’expérience avec WCF. Si on arrive dans un autre mandat ou projet et que le générateur n’existe pas, il nous faudra approfondir WCF car finalement, on ne le connaît pas vraiment malgré son utilisation dans un précédent projet.
  • Difficultés lors de la recherche d’erreurs : Les générateurs de code produisent en général du code un peu obscur et difficile à lire. Si une erreur se produit dans cette partie du code, la recherche peut s’avérer longue et douloureuse.
  • Pour une simple correction, on a souvent pas le choix d’utiliser le générateur de code: C’est en général non-productif de devoir refaire l’exécution du générateur pour faire un petit changement, comme renommer une méthode par exemple ou changer de type une propriété. Pour ces gestes, c’est tellement plus facile et rapide d’y aller manuellement…

Bien que j’aie déjà utilisé certains de ces outils, je peux avouer qu’ils sont parfois efficaces et, probablement, valent la peine d’être utilisé selon le contexte. Dans certains environnements avec des dizaines de programmeurs, on n’a pas trop le choix de standardiser certaines parties du code malgré les inconvénients. Bref, je crois que l’idéal est d’avoir une bonne balance entre productivité à court terme et l’apprentissage à long-terme.

Voici quelques-unes de mes expériences avec les générateurs de code:

Bonnes:

  • LINQ to SQL: Le code généré à partir de tables SQL Server n’est pas trop gros. C’est certain qu’il n’est pas très beau non plus, mais c’est assez facile de se créer une classe « extended » pour y ajouter des options particulière, comme une chaîne de connexion qui peut changer selon certaines conditions. Mais dans ce cas, le gain se fait surtout par l’utilisation directe de LINQ pour lire et modifier nos classes SQL. Le code que l’on créé ainsi manuellement est beaucoup plus lisible et simple avec LINQ.
  • Resharper: La génération de code dans Resharper se charge surtout de petits bouts de code qui seront intégrés à notre classe. Après cela, on les manipule comme on veut. Voyez ici les exemples .

Négatives:

  • Smart Client Software Factory: Il y a une bonne volonté ici de faire des outils pour générer nos vues, contrôleurs et autres structures nécessaire au pattern MVP-C. Par contre cela en résulte en un nombre assez nombreux d’événements. Lorsqu’il faut faire du débogage, on ne se sait plus trop ou donner de la tête lorsque cela saute d’un événement à l’autre.
  • CodeSmith : J’ai déjà utilisé cet outil pour générer une couche d’accès aux données dans un précédant projet. Je trouvais terrifiant de voir des milliers de lignes de codes produite pour simple une table avec une dizaine de colonne seulement. Par chance que les erreurs ne s’y trouvaient pas souvent. Noter aussi que CodeSmith a d’autres outils que je n’ai pas essayé et qui sont probablement intéressant malgré tout.
  • L’outil « Add Service Reference » de Visual Studio pour WCF: Je n’aime pas cette option qui se fait un peu trop facilement avec un clic droit de la souris. Le gros problème c’est que le fichier de configuration est rempli plein d’options sélectionnés dont plusieurs ne sont pas utile. Aussi, c’est un peu embêtant si on ajoute un deuxième service en référence dans le même projet. J’aime beaucoup mieux la méthode manuelle tel que décrit dans l’article WCF the Manual Way…the Right Way

Et vous, que pensez-vous des générateurs de code ?

Trouvailles sur slideshare

Connaissez-vous Slideshare ? Sinon, vous manquez quelque chose car on y trouve plusieurs présentations très inspirantes. Sildeshare est un peu comme le YouTube des présentations. On peut donc y faire des recherches et y trouver des présentations sur divers sujets que des gens d’un peu partout ont créées. Aussi, on peut se créer un compte et y conserver ses préférés.  Vous trouvez donc mes trouvailles sur ce lien (que je mettrai à jour régulièrement):
 
http://www.slideshare.net/kmetivier/favorites 

Parmi mes préférés, je vous recommande les présentations suivantes: 

Basics Of Social Media Roi 
Super belle présentation sur les médias sociaux et leur ROI. J’aime beaucoup les images prises des vieilles séries des années 70. 

Wireframing For Web CMS Projec
Bel exemple de comment passé d’une conception de basse fidélité vers une de haute fidélité. On parle aussi de l’importante de faire des esquisses et des brouillons avant de se lancer dans le développement proprement dit. Je vais sûrement essayer d’appliquer ces principes dans un futur projet.

 How to make your retrospectives the HEART of your agile process
Les rétrospectives sont un facteur de succès pour tout équipe, en mode agile ou pas. Yves Hanoulle nous fait découvrir les différents étapes d’une rétrospectives de manière imagée.

The Shy Connector
Sacha nous parle ici de comment se connecter à d’autres personnes, même si on est de nature introvertie. J’aime bien aussi la manière de faire des présentations plus personnelle avec nos propres dessins.

Tout cela me donne le goût aussi de partager mes présentations ou d’en créer des nouvelles…

Critique de livre : The Five Dysfunctions of a Team

FiveDysfunctionsCover Ce livre n’est ni technique et ne parle pas d’agilité. Pourquoi donc j’en ai fait la lecture ? Et bien tout a commencé cet été lors de mon passage à la conférence Agile 2009 qui a eu lieu à Chicago, lorsque j’ai assisté à la présentation suivante :

Scaling Up by Scaling Down: A (re)Focus on Individual Skills

Dans cette présentation sur le comment faire progresser une équipe pour la rendre hyper-performante, on mentionnait le livre en référence. Intrigué, je me suis procuré le livre en question sur les 5 dysfonctions d’une équipe. En passant, la présentation a été filmée et vous pouvez donc l’entendre au complet sur le site d’infoQ:

http://www.infoq.com/presentations/scaling-up-by-scaling-down

Je vous la recommande fortement si vous voulez en savoir davantage sur le leadership d’équipe et le lien avec l’agilité. Le conférencier, Ashley Johnson,  parle avec un anglais qui est en général très facile à comprendre.

Pour revenir au livre, c’est un bon livre et j’ai l’est vraiment aimé. Il est d’ailleurs utile pour tout ceux qui sont intéressé par le travail d’équipe, peu importe leur rôle. C’est une lecture assez facile, cela m’a pris environ 1-2 semaine pour le terminer. De plus, son contenu est présenté ainsi, de manière peu conventionnelle:

  • Les 184 premières pages du livre racontent une "fable" sur le leadership.
  • C’est dans les 40 dernières pages que le modèle des 5 dysfonctions nous est décrit.

J’ai trouvé très instructif ce format. On nous fait découvrir graduellement la théorie des 5 dysfonctions d’une équipe à travers une histoire fictive, mais très réaliste. On devient rapidement accroché à l’histoire et on a hâte de voir la suite et comment l’équipe va réussir à corriger ces 5 dysfonctions. Ce format nous permet de comprendre la théorie à travers une histoire au lieu d’y aller directement avec la théorie sans trop de concret. Ah si les écoles fonctionneraient de cette manière…

Pour les 5 dysfonctions d’une équipe je les résume ainsi avec une traduction libre :

  • Manque de confiance envers les autres (Absence of trust)
  • Peur des conflits (Fear of conflicts)
  • Manque d’engagement (Lack of commitment)
  • Éviter la responsabilisation (Avoidance of accountability)
  • Inattention aux résultats (Inattention to results)

On doit commencer idéalement par résoudre la première dysfonction, ici le manque de confiance, et résoudre les autres en ordre par la suite pour finir avec le dernier, soit l’inattention aux résultats.

Vous trouverez le détail de ces dysfonctions dans les documents suivants disponibles:

Autre bon résumé si vous avez moins de 5 min, écouter l’auteur du livre, Patrick Lencioni, nous décrire brièvement les 5 dysfonctions:

 

Pour poursuivre mon habitude des points clefs, voici ce que je retiens de cette lecture :Darts 

  • Si on se retient de dire des choses de peur de confronter les autres, cela nuit grandement à rendre une équipe fonctionnel
  • Viser le consensus de toute l’équipe n’est pas toujours la bonne chose à faire. L’important c’est que tous les membres de l’équipe aient eu l’occasion de s’exprimer. Après, la décision passe beaucoup mieux au sein de l’équipe.
  • Je vois bien intégrer ce genre de modèle aux pratiques de rétrospective et d’amélioration continue d’une équipe Agile. À essayer donc lors d’un prochain projet.