Les pratiques qu'on kiffe

Ca fait quelques jours que je vois passer des tweets sur un jeu lancé par @pablopernot. Comme je sais que Pablo aime bien le feedback -il en a déjà eu pas mal- voici le mien.

Pablo a publié un article sur ce jeu puis un deuxième après un premier feedback.

Le nom du jeu

Alors je n'aime pas du tout adn-agile. On entend à longueur de journée l'expression "c'est pas dans mon adn", c'est complètement galvaudé.

Mais surtout j'y vois un gros risque de confusion : l'ADN c'est ce qu'on est, or le jeu porte sur les pratiques, ce qu'on fait. Un titre avec ADN aurait du sens si le jeu portait sur les valeurs agiles.

A ce propos, un autre jeu sur le même principe mais avec des valeurs écrites sur les cartes, c'est tout à fait pertinent lorsque l'équipe se constitue dans le sprint zéro pour constituer sa liste initiale de valeurs partagées, à remettre à jour à chaque rétrospective.

Donc, comme nom pour le jeu qui consiste à converger vers la pratique préférée, je propose : PRATIKKONKIF.

Cela me rappelle qu'en 2008, j'avais fait un billet sur la pratique agile préférée de mes étudiants.

Les pratiques

L'exercice qui consiste à élaborer une liste de pratiques est délicat. Jurgen Appelo s'y était risqué en 2009, avec sa big list. L'Institut Agile a défini un référentiel des pratiques, qui en contient plus d'une soixantaine. Dans le chapitre 12 de mon livre sur Scrum, j'en cite une vingtaine.

Voilà mon feedback sur les pratiques proposées dans le deuxième billet de Pablo.

Pratiques conservées (20)

Bien sûr, je ne suis pas d'accord avec l'argument de l’homogénéité pour garder les termes anglais. Le but du jeu étant de provoquer des discussions sur l'essence des pratiques, la langue maternelle, quand c'est possible, me paraît bien plus appropriée. Je garde l'ordre et je mets entre parenthèses le mot anglais proposé, quand c'est nécessaire :

  • Rétrospective
  • Scrum quotidien
  • TDD
  • Planification de sprint
  • Tests d'acceptation
  • Revue de sprint
  • Définition de fini
  • Backlog
  • Tests automatisés
  • Limite de TAF - Travail à finir (Limit work in progress)
  • Conception émergente
  • Management visuel
  • Intégration continue
  • User story
  • Personas
  • Refactoring
  • Impact Mapping (que je sépare de Story Map)
  • Niko niko ou Indicateur de la satisfaction de l'équipe
  • Plan de release
  • Estimation en points

Pratiques non conservées (13)

  • BDD inclus dans Test d'acceptation
  • Burndown chart for tasks (inclus dans scrum quotidien)
  • Burnup chart for stories inclus dans plan de release
  • Timebox inclus dans Sprint et Release
  • Validation inclus dans Définition de fini
  • Vélocité inclus dans Plan de release
  • Vision remplacé par Impact Mapping
  • Revue par les pairs (voir essaimage)
  • Given then when inclus dans Test d'acceptation
  • 5 pourquoi (trop marginal)
  • Priorisation inclus dans Backlog
  • Stream value map (trop marginal)
  • War room -Obeya (voir Management visuel)

Pratiques élargies ou revues (3)

  • Essaimage plus large que pair programming, pour ne pas limiter à 2 et à la programmation
  • Sprints et releases plus large qu'itération et incluant la notion de timebox
  • Jeux agiles innovants pour la définition de produit (pour ne pas dire innovation games, que Pablo n'a pas voulu écrire mais je trouve qu'Agile Games est trop large)

Pratiques ajoutées (5)

3 qui sont absolument fondamentales manquent de mon point de vue :

  • Product Owner
  • ScrumMaster
  • Equipe pluridisciplinaire et auto-organisée
  • plus Story Map
  • plus ce qu'on pourrait appeler Intraspective pour reprendre le mot de Dan Rawsthorne qui est -en gros- l'identification et la résolution des obstacles pendant le sprint (la technique des 5 pourquoi est utilisable pour cela).

Bien sûr tout cela est très subjectif et dépend du contexte. Certaines pratiques n'auront pas de sens dans certains contextes (par exemple les pratiques d'ingénierie logiciel si on est dans un restaurant).

C'est pourquoi je suggère de garder 4 cartes vierges pour que les participants puissent ajouter des pratiques d'ingénierie spécifiques de leur contexte, au début du jeu.

Cela ferait arriver à 32 cartes, ce qui me paraît largement suffisant.

Déroulement du jeu

Pour donner du feedback, je vais attendre d'y jouer. Tiens je vais proposer de faire une session dans le cadre d'Agile Toulouse, après le Kanbanzine de lundi.

Simplement, il me semble que le nombre de pratiques à sélectionner dans l'étape 3 dépend du nombre de participants et que pour des petits groupes, 8 devrait suffire. A voir.

En plus du contexte il me paraît essentiel de définir l'objectif du jeu. On n'aura pas le même résultat si le but est d'obtenir la pratique préférée ou, par exemple dans le cadre d'une rétrospective, celle à améliorer.