Depuis quelques années j'ai pris l'habitude avec mes amis coachs craft de commencer les accompagnements Agile / Craft / DevOps / Continuous Delivery par des évaluations individuelles des développeurs (vending machine) à base de katas. L'idée est d'avoir par la pratique une idée du point de départ, ce qui aide à tailler l'effort d'accompagnement. Récemment, un nouveau besoin s'est fait ressentir à savoir être capable d'évaluer la capacité des personnes à travailler en équipe. D'où la naissance du kata badminton qui a pour objectif d'évaluer la capacité d'une équipe à comprendre le besoin, définir des incréments de valeur, construire un produit et le déployer. Ce kata peut être utilisé soit en entraînement soit en évaluation. A la différence du fruit shop ou de l'extreme carpaccio, il se joue en équipe complète.
Déroulé
En prérequis, il est demandé à l'équipe de :
Construire un produit. Pour ce faire, Il est nécessaire que tous les développeurs aient un écosystème de développement opérationnel.
De déployer les incréments du produit, cela sous entends de mettre en place une usine logicielle à minima.
C'est un kata de type : green field (zéro ligne de code au début) donc un nombre de lignes de code limité.
Au début du kata, je donne l'énoncé à tout le monde et j'explique le besoin : "Je suis un président d'un club de badminton et je veux une application pour faire un tournoi permanent entre les membres du club". Ensuite, je demande toutes les 15 minutes ce que je peux voir sachant que je leurs laisse 2 heures (debrief non compris).
Conseil : Deux heures suffit pour évaluer, trois heures si vous êtes en mode entraînement.
Pendant tout le déroulé, les coachs restent assez proches pour pouvoir ensuite donner du feedback.
Grille d'analyse / Ce que l'on peut voir
Voici les points qui sont visibles sur lesquels il est possible de dégager facilement des axes d'amélioration.
Produit
- Besoin vs Solution : La notice donnée est très orientée solution et pas vraiment besoin. Il est intéressant de noter les questions posées par le Product Owner et à un degré moindre celles de l'équipe pour voir si l'équipe va chercher à répondre à un besoin ou à développer le cahier des charges.
- Découpage en incrément de valeur aussi appelé slicing : La notice donnée est complète et très adaptée à une approche cycle en V. Dans le temps imparti, il est possible (et souhaitable) de faire de la livraison incrémentale de valeur. Lors du dernier kata, le product owner a par exemple utilisé une story map pour les identifier.
- Spécification par l'exemple : Dans le kata, il s'agit de regarder comment les fonctionnalités sont exprimées pour les développeurs sur la partie jeu d'essai. Je n'ai pas donné d'exemples dans la notice car j'attends qu'ils émergent de l'équipe.
Agile mindset
- Séquencement : C'est tout ce qui tourne autour de l'organisation mise en place pour planifier/estimer ce qui peut être fait dans le lapse de temps donné, puis exécuter de manière itérative et incrémentale et enfin s'améliorer au fur et à mesure. Ce dernier point est cependant plus dur à appréhender.
- Est ce une équipe par le prisme des 5 dysfonctions d’une équipe ? confiance, confrontation des idées, engagement individuel, responsabilisation mutuelle, attention aux résultats
Craft
- TDD/Clean code : Il y a peu de fonctionnalités mais assez pour que le TDD et le clean code soient applicables. Comme les personnes sont légèrement stressées par le kata, elles ont plutôt tendance à faire ce qu'elles savent faire en mode survie. C'est une autre façon de dire que les tests unitaires prennent souvent chers sur ce kata.
- Pair programming : Il n'y a pas 10.000 fonctionnalités à développer en même temps et donc cela pousse plutôt à adopter une approche de type pair programming.
- Branching : C'est pas si simple à voir car du green field et peu de paires style (1 paire sur le front et 1 paire sur le back)
DevOps
- Pipeline : Il est demandé de livrer sur un environnement qui permet un test manuel. Et donc est assez facile de se faire une idée sachant que si le pipeline ne marche pas, il est possible de regarder des démos plus locales.
Limites voulues
Quand j'ai créé le kata, j'avais en tête de regarder le product delivery. Ne croyant pas au kata universel, j'ai exclu des thèmes d'analyse:
- Les aspects sécurité ne sont pas regardés.
- Au vu du timing court, l'équipe ne peut quasi pas prendre en compte les feedbacks de démo qui engendreraient un rework sur le déjà fait.
- Sur le testing, il n'y a pas de contrainte exprimée sur performance et charge.
- Pas vraiment d'opportunité de faire du DDD.
- Je demande aux personnes d'utiliser des technologies avec lesquelles elles sont confortables. Il n'est pas simplissime et donc l'utiliser sur une techno non maîtrisée me parait casse gueule.
Le mot de la fin
Si vous le jouez, n’hésitez pas à nous faire des retours pour que nous puissions l’améliorer.
