Les valeurs de XP, Scrum, Kanban et ... les tiennes

Publié par Louis-Philippe Carignan le jeudi 28 février 2013 à 07:19

Oui, oui, je sais. On est super loin du code lorsqu’on parle des valeurs des méthodologies. Pourquoi m’embêtes-tu donc avec ça Louis-Philippe quand j’éprouve un grand plaisir à juste coder pendant ma journée?

C'est qu'il y a quelques années, j’étais à une formation de Lyssa Adkins où elle m’a demandé pourquoi j’étais impliqué dans l’Agilité. Je n’ai pas su quoi répondre et en haussant les épaules, Lyssa a vogué vers un autre groupe de personnes, sachant qu’elle venait de me faire réfléchir.

Plus tard dans la journée, Lyssa présentait une pyramide inversée qui expliquait que les valeurs étaient à la source des principes et des pratiques mis en place par la suite. J’ai encore cette photo bien que cela fasse plus de deux ans que j’aie assisté au cours.

Process Architecture

D’ailleurs, j’avais aimé le commentaire de Lyssa suite à ce dessin. Elle a fait référence au Projet Management Body of Knowledge (PMBoK) qui « presents a set of standard terminology and guidelines for project management » selon l’article sur Wikipedia. À mon avis, le PMBoK contient un tas de pratiques mais elles ne sont pas supportées par des principes et des valeurs, contrairement à l’Agilité qui a un manifeste et 12 principes.

Plusieurs mois après son cours, je complétais ma demande pour être formateur chez Scrum.org. Le formulaire m’a presque posé la même question que Lyssa. Cependant, j’y avais réfléchi longuement (merci Lyssa) et la réponse fût facile à écrire. Pour moi, les valeurs dans l’Agilité étaient en lien avec mes valeurs personnelles. Cela était donc facile pour moi de m’approprier ce truc puisque c’était comme si je parlais de moi. Je savais qu’en l’enseignant, les participants sentiraient vraiment mon intérêt pour ces approches et que cela ferait de moi un bon professeur (du moins, je l’espère).

À partir de ce moment, j’ai toujours cherché à identifier les valeurs présentes dans une équipe, un département ou une organisation dans laquelle je me retrouvais. Par exemple, si j’entendais une phrase comme « On a essayé Scrum mais ça ne marche pas », j’essayais d’identifier les valeurs dans l’équipe ou le département pour voir si la culture en place a tout simplement étouffée l’initiative.

Les valeurs de la méthode Kanban

J’ai été agréablement surpris de trouver un billet publié en janvier 2013 à propos des valeurs de Kanban. L’auteur, Mike Burrows, décortique les pratiques et principes de la méthode Kanban pour énoncer 9 valeurs qui supportent Kanban.  En lisant les commentaires sur le groupe Yahoo! Kanbandev, les réactions face à ce billet étaient majoritairement positives.

Voici donc les 9 valeurs de la méthode Kanban :

  • Transparency
  • Respect
  • Understanding
  • Leadership
  • Flow
  • Customer Focus
  • Agreement
  • Balance
  • Collaboration

À titre comparatif, j'ai créé le tableau ci-dessous pour mettre en parallèle ces valeurs à celles de Scrum et Extreme Programming. Les valeurs d'Extreme Programming sont détaillées dans la page Wikipedia tandis que les valeurs de Scrum ne sont pas listées. Bon, pour le bien de l’article je vais mettre les trois pilliers de Scrum ainsi que l’engagement (Commmitment) et le focus dans les valeurs de Scrum.

XP

Scrum

Kanban

Communication

Respect

Feedback

Courage

Simplicity

Transparency

Inspection

Adaptation

Commitment

Focus

Transparency

Respect

Understanding

Leadership

Flow

Customer Focus

Agreement

Balance

Collaboration

Si on revient au dessin de Lyssa au début du billet, les pratiques mises en place par ces méthodes sont supportées par un ensemble de valeurs qui leur sont propres. Par exemple, dans la méthode Kanban, l’un des principes est de visualiser le travail. On s’appuie sur la transparence pour établir ce principe et il y aura sûrement toutes sortes de pratiques qui émergent de ce principe. Mais si des gens dans l’équipe n’aiment pas montrer où ils sont rendus, et cela existe, ils auront de la difficulté à embarquer. Parce que naturellement, au fond d’eux-mêmes, ils vont résister parce qu’ils ne connectent pas avec cette valeur.

Dans un autre exemple, je me suis déjà retrouvé dans une équipe de développement où il était mal vu de dire qu’on allait dépasser nos estimés. Bien que les membres de l’équipe aient du courage pour admettre que certaines parties du logiciel étaient mal programmées, la culture de l’entreprise ne permettait pas de cultiver cette valeur. Difficile alors de mettre en place des dojos pour faire du refactoring lorsque la culture s’attend à ce que le travail soit parfait du premier coup.

Et c’est là que toi, la personne qui lit ce billet, doit se demander quelles sont tes valeurs personnelles, celles de tes collègues, celles de ton département, et voir si elles concordent avec les valeurs de la méthode que tu essaies de mettre en place. Tu veux de l’Agilité. Parfait. Tu veux mettre en place la méthode Kanban. Parfait. Mais avant d’envoyer ton monde en formation, je t’invite à identifier les valeurs de la méthode qui sont moins présentes dans ton équipe/département. C’est peut-être là que les premiers problèmes vont surgir lorsque vous allez mettre la méthode en place.

Mots-Clés :
blog comments powered by Disqus

0 Comments:

Post a comment

Comments have been closed for this post.