Lors du keynote des ScrumDays 2014, Alistair Cockburn s’intéresse à l’évolution de l’Agile, du manifeste à aujourd’hui. Il fait mention notamment d’une notion dont je ne connaissais pas le nom: Shuhari. D’abord apprendre, ensuite se détacher, finalement transcender. Concept qu’il intègre à sa manière d’être un professionnel agile, et auquel on se retrouve parfois confronté de manière fortuite.

Extrait de la page wikipedia:

Shuhari est un concept issu des arts martiaux japonais qui décrit les 3 étapes de l’apprentissage. Il est parfois appliqué à d’autres disciplines comme le jeu de go.

ShuHaRi peut se traduire par suivre les règles, comprendre les règles et transcender les règles.

  1. Shu (守:しゅ, “protéger”, “obéïr”) — sagesse traditionnelle – apprendre les fondamentaux
  2. Ha (破:は, “se détacher”, “digresser”) — casser avec la tradition — trouver les exceptions à la sagesse traditionnelle, trouver de nouvelles approches
  3. Ri (離:り, “quitter”, “se séparer”) — transcender — il n’y a pas de technique ou de sagesse traditionnelle, tous les mouvements sont permis.

A/ Le contexte

Mettre en place une équipe transverse à l’aide de Scrum est compliqué.

Lorsqu’il s’agit d’une équipe composée de développeurs et d’administrateurs qui ont à la fois:

  • la responsabilité de l’exploitation de plusieurs produits et donc dont les journées de travail peuvent être interrompues à n’importe quel moment pour une difficulté en production,
  • la mise en place de services d’infrastructure pour les développeurs,

cela devient un casse-tête infernal.

Dans ce cadre, dépasser, évoluer et ne pas rester dans le cadre et les techniques habituelles est indispensable. A vouloir trop rester rigide, à manquer d’agilité et de souplesse, le mur n’est pas loin. Cependant, cela ne se fait pas en une seule étape. Dans les grandes lignes, voici la manière dont l’équipe a adapté son fonctionnement à son identité.

 

B/ Shu.

Lorsque j’ai commencé à travailler avec l’équipe, rien n’existait pour comprendre l’état d’avancement des sujets. Ni gestion de projet classique, ni agile. Rien. Celle-ci est composée d’un développeur et d’un administrateur serveur. Avec le support d’un style bien traditionnel, les deux personnes discutent peu et lorsque c’est le cas, ne se comprennent pas.

 

– Tu comprends Fred, le problème c’est que dev et admin, ce n’est pas le même métier. Les devs, ils codent vite et parfois oublient qu’il y a une prod derrière. Nous, en tant qu’admins, on passe notre temps à réparer après.
– Les admins sont trop psychorigides, du coup, ça n’avance pas. Il faut toujours les pousser pour qu’ils fassent quelque chose, c’est pénible. On pourrait déjà gérer plein de produit, là on piétine depuis des mois.

Rien d’inhabituel, vraiment, si ce n’est que j’ai rarement autant entendu de ma vie “le problème c’est que” pour démarrer une phrase.

J’ai accompagné la mise en place du Scrum “by the book”, avec un peu de résistance, mais surtout de l’incrédulité.

– Ecrire des post-its, c’est pas vraiment utile.
– Et les stand-ups, c’est pénible, à deux.

Le deuxième argument est devenu assez rapidement caduque: l’équipe est passée à quatre personnes au bout de quelques sprints, suite aux besoins remontés pendant les rétrospectives. Au-delà de leur incrédulité, l’équipe dans son ensemble a convenu que les “choses” (terme générique largement utilisé pour décrire ce qui nous paraît imperceptible) allaient mieux.

Si tout ne convenait pas dans le Scrum pour cette équipe, les rétrospectives leur ont offerts un espace de discussion apaisé, dans lequel les frustrations ont pu être nommées et des actions pour les faire disparaître identifiées. Notamment les frustrations paradoxales d’avoir le sentiment d’aller trop vite et  d’avoir l’impression de piétiner.

Par contre, nous avions toujours des soucis de finition sur certaines stories. L’effet “démo” (ou comment se retrouver à 5 à regarder une invit. de commandes qui ne fonctionne pas en se demandant ce qu’on fait là) était largement apparent.

Bizarrement, le code review ne suffisait pas et l’ajout de tests automatisé, à chaque nouvelle version d’un bloc d’infrastructure, difficile à considérer. Automatiser des tests qui lanceraient une cinquantaine de machines virtuelles sur Amazon était un coût que nous ne pouvions nous permettre, le ROI mauvais, même en les faisant tourner qu’une fois par jour.

Et, en dehors de cela, quid des problèmes de production? Les problèmes en production sont récurrents mais à des intervals complètement aléatoires. Certains sprints se déroulaient avec, d’autres sans. Difficile pour l’équipe de prendre un engagement lors du planning…

 

C/ Ha.

HaUn problème à la fois. Quitte à ne pas réussir à fournir toutes les stories pour un sprint donné, nous avons collégialement accepter de prendre en compte que l’on faisait au mieux (prime directive des rétrospectives).

De mon point de vue, le premier soucis est avant tout la qualité de ce qui est fourni, plutôt que le volume de ce qui est validé.

Nous avons donc commencé par le fameux l’effet demo.

Je ne suis pas allé trop loin pour proposer la chose. Une autre équipe, coachée par une autre Scrum Master, avait pris l’habitude de faire des “mini-démos” entre développeurs pendant le sprint. Cela leur permettait de limiter la casse le jour J et de s’assurer que tous les membres de l’équipe avaient connaissance du contenu du sprint.

Donc, nous avons mis en place ce système. Dès qu’un sujet était terminé, la personne qui en était responsable le présentait aux autres. Le résultat sur le déroulement des sprints reviews a été immédiat.

Intégrer des idées qui viennent d’autres équipes expérimentées est toujours utile. Parfois, la meilleure manière de palier à une difficulté ne se trouve pas dans le Scrum Guide (qui n’existe pas pour cela, de toute manière…)

 

D/ Ri.

Ri

Ou: Le modèle “Task Force”.

Lors d’une rétrospective, nous avons convenu ensemble que la notion de sprint ne pouvait pas s’appliquer pour l’équipe. En effet, l’engagement étant difficile à tenir pour des raisons extérieures que nous ne pouvions modifier, celui-ci se transformait plus en facteur de stress et de frustration qu’en quoi que ce soit de positif. Or, nous recherchons exactement l’inverse…

L’idée d’origine est venue de l’équipe, je me suis essentiellement contenté de la reformuler.

Nous avons:

  • mis à bas les sprints,
  • conservé des démonstrations rapides à la fin de chaque sujet,
  • gardé une démonstration plus générale toutes les deux semaines,
  • maintenu les rétrospectives.

 

  • Le Scrum Board est devenu une sorte de Kanban,
  • Les sujets ont été divisés en tâches pouvant être mises en oeuvre en deux jours, pour se permettre un switch rapide entre mise en place de services et exploitation,
  • Nous avons convenu que chaque sujet serait pris en charge par deux membres de l’équipe, pour faciliter la collaboration, la rapidité et la fiabilité de ce qui est produit.

Ce qui nous a donné ceci:

task force mode

 

E/ Conclusion

Scrum est une bonne méthodologie pour le développement de nombreux produits, même s’il n’est pas toujours l’outil le mieux adapté à toutes les équipes et besoins.

Cependant, pour trouver un bon mode de fonctionnement, il est nécessaire de partir d’une base connue. Du moins, c’est plus simple. Une fois la base en place, il est temps de la faire évoluer en la remettant en cause dans ses propres dysfonctionnements. Il est assez logique que l’Agile trouve dans cette notion de “ShuHaRi” des principes qui correspondent parfaitement.

En bilan de tout cela, nous disposons aujourd’hui d’une équipe DevOps qui est à même de collaborer avec les équipes produits, tout en maintenant l’exploitation.

Les différents entre développeurs et admins sont, eux, devenus quasi-inexistants au bout de quelques sprints. Les membres de l’équipe ne se cachent plus derrière leurs professions respectives pour expliquer les dysfonctionnements et acceptent, avant tout, les différences de personnalité des autres – qui, elles, sont bien réelles.


 

Références: