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.
Publicités

Agile Tour 2009: Ressources post-événement

at2009_quebecPour faire suite à la conférence Agile Tour Quebec 2009, j’ai réuni dans ce blogue, des liens diverses qui parle de cet événement. S’il m’en manque, juste à m’en aviser et je vais mettre à jour cette page en les ajoutant.

Articles:

Présentations:

Blogues des présentateurs:

Acceptance Test Engineering Guide, volume 1 BETA2 release

image

Vous vous souvenez de Grigori Melnik ?

Il est venu l’an passé à la communauté Agile de Québec pour parler de l’approche Agile. Voir ici pour détail de cet événement passé : http://blogs.cunq.org/blogs/agileqc/archive/2008/04/28/201-v-233-nement-l-approche-agile-par-grigori-melnik.aspx

Et bien Grigori Melnik et son équipe viennent de compléter le beta 2 du volume 1de leur livre « Acceptance Test Engineering Guide ». Il demande à la communauté des volontaires pour faire la revue de ce volume 1.

Vous trouverez les détails à l’article suivant de son blogue :

http://blogs.msdn.com/agile/archive/2009/06/30/acceptance-test-engineering-guide-volume-1-beta2-release.aspx

Est-ce que le TDD augmente la vitesse de développement ?

Bon, retour à mon blogue après quelques mois de pause. Je me suis permis aussi un petit relooking à mon blogue.

image

Bon, revenons au sujet de ce blogue:

Est-ce que le TDD (Test-Driven Development) augmente la vitesse de développement ?

D’un point de vue d’un programmeur concentré sur sa tâche, la réponse est non. Les tests sont un surplus de travail pour lui.

Par contre, si ouvre un peu plus notre horizon et si on regarde pour voir quelle est la place de la tâche de programmation dans le processus global, on retrouve une nouvelle perspective:

L’activité de développement consiste à faire tout le travail pour amener un concept ou un besoin à se transformer en valeur ou si vous préférez turning concept into cash. Cela commence avec une idée et se poursuit avec la conception, l’implémentation et la livraison.

Alors oui, le TDD augmente la vitesse de développement car il permer de:

  • Écrire le code sans bogue ou défaut de conception au premier jet
  • Répondre avec précision au besoin du client
  • Diminuer la complexité
  • Rend le code "agile" et plus facile à modifier.
  • Et bien d’autres avantages…

Scott Bellware, toujours intéressant dans ses propos, parle de tout cela dans un récent article de son blogue. Je vous invite à aller lire l’article en question:

http://blog.scottbellware.com/2008/12/does-test-driven-development-speed-up.html

Outils pour l’agilité

j0431711 Kent Beck, l’un des fondateurs du XP Programming, a écrit récemment un article, "Tools for Agility", sur l’importance des outils avec les méthodologies agiles. Voici un petit résumé de ses propos:

Dans le manifeste agile on parle entre autre de miser davantage sur les individus et les interactions que sur les outils et les processus de développement lourds.

Mais cela ne veut pas dire qu’on n’a pas besoin d’outils. On ne parle pas ici de retourner à l’âge de pierre pour écrire nos plans de projet sur des murs de pierre !!!

La priorité des outils était dans une approche de type "Waterfall" est de supporter efficacement une activité donné. Maintenant, les outils doivent supporter efficacement le changement fréquent d’activité, comme c’est le cas avec l’agilité.

Comme on effectue des livraisons fréquentes de nouvelles fonctionnalités, il y a davantage de transitions entre ces activités. L’image suivante représente bien ce problème de transition dans un mode agile:

image

La plupart des pratiques agiles ont donc besoin d’outils qui sont ajustés à ce rythme de développement. On ne pourrait pas faire de l’intégration continue sans des outils comme CruiseControl, FinalBuilder ou VSTS. Même chose pour le TDD, le refactoring et la planification itérative.

Si vous voulez en savoir plus sur l’impact des outils dans un mode agile et aussi sur l’avenir de ces mêmes outils, je vous recommande de lire l’article en question:

Tools for Agility by Kent Beck

La collaboration Agile chez Microsoft

Voici un lien vers un petit vidéo fort intéressant de l’équipe "Patterns and Practice" de Microsoft. Des membres de l’équipe décrivent leur environnement de travail très axé sur l’agilité. J’aime bien le concept des tableaux blancs un peu partout et du rapprochement des équipes dans le but de favoriser la collaboration.

http://msdn2.microsoft.com/en-us/practices/cc304589.aspx