Lean Kanban France 2015 : Michel-Ange et des HiPPo

PALO IT m’a proposé d’assister pour la première fois au Lean Kanban France 2015. Je m’y suis rendue sans préjugés, mais avec des attentes particulières. Vais-je apprendre quelque chose de concret qui pourra me servir dans mes missions, ou vais-je juste entendre des conseils pleins de bon sens mais qui ne sont applicables que dans un monde idyllique où toute transformation Agile se fait en un claquement de doigt, comme par magie ?

Le programme du Lean Kanban est bien pensé. Il cible les profils déjà confrontés à des situations complexes et qui espèrent que l’Agilité les aidera à améliorer leurs conditions de travail. Certaines présentations se veulent plus académiques, comme « Appliquer Kanban sur Scrum » de Claude Aubry. D’autres n’ont pas la prétention de vouloir nous faire découvrir un nouvel outil ou une nouvelle méthodologie qui vont révolutionner notre manière de travailler. Mais elles abordent des valeurs chères à l’Agilité de manière ludique.

J’ai choisi de couvrir les deux conférences ci-dessous :

« How to train your HiPPO » de Özlem Yüce

Mais qu’est-ce qu’un HiPPO ? Voici la définition de Özlem Yüce :

The HiPPO is the Highest Paid Person’s Opinion. When we allow the HiPPO to drive decision-making we hide critical assumptions. Value and urgency is buried. Batch size is increased. Dates are promised. Options are prematurely closed down. False constraints back us into a corner. Costs are squeezed. The chances of discovering black swans is reduced. The risk of failure increases. Indeed, the HiPPO is one of the most dangerous animals to let stomp around in Product Development.

HiPPO conference

Sous forme d’anecdotes amusantes, Özlem Yüce nous explique pourquoi l’HiPPO est un animal dangereux. On rit tous, car en l’écoutant, nous avons tous en tête des HiPPO qui nous ont mis arbitrairement sous pression. C’est le genre de présentation qu’il faut voir en live pour l’apprécier, comme un one man show ! A défaut, je vous propose un résumé de son programme pour éduquer votre HiPPO en 5 étapes :

  1. Rendre visible les problèmes:
    Par exemple, on peut afficher des métriques qui mettent en évidence le temps passé à récupérer des informations au lieu de produire, ou bien le temps passé à produire du travail qui n’est pas utilisé.
  2. Questionner avec humilité
    On peut questionner l’HiPPO de manière naïve afin de lui suggérer une solution qui nous arrange, sans lui donner l’impression de remettre en question sa décision arbitraire.
  3. Appliquer la règle des 3
    « Avoir un seul choix revient à n’avoir aucun choix. Avoir 2 choix revient à un dilemme. Avoir 3 choix offre des nouvelles possibilités ».
  4. Parallel Thinking
    Utiliser cette méthode pour inciter l’équipe à collaborer ensemble et plus efficacement. Pour plus d’information, vous pouvez regarder la méthode « Six thinking hats ».
  5. Être pragmatique
    « Y a-t-il de réels bénéfices à livrer dans un mois plutôt que dans deux mois? », sous-entendu : « Si cela ne change pas grand-chose, autant livrer dans deux mois, non ? »

J’ai également passé un très bon moment. Özlem Yüce utilise la métaphore et l’humour pour nous démontrer que nous avons la possibilité de faire changer les choses, plutôt que de subir des décisions arbitraires qui nous mettent sous pression. Son mot de la fin est juste parfait «Don’t be a HiPPOcrite ». A méditer…!

Pour revoir la vidéo de sa présentation, cliquez ici : https://www.youtube.com/watch?v=Gov38g_N5rw

« Si le TDD est mort, alors pratiquons une autopsie » de Bruno Boucard et Thomas Pierrain

Le titre est prometteur. Et ça tombe bien car je cherche toujours la meilleure solution pour avoir des tests de qualité qui permettent de détecter rapidement les bugs et régressions, avec bien entendu, un coût de mise en place et de mise à jour défiant toute concurrence. Qui n’a jamais travaillé dans un projet où les développeurs ont arrêté de maintenir les tests automatisés car il était moins chronophage de les désactiver et de tester manuellement ? J’ai également déjà été confrontée au cas d’un projet avec une couverture de tests importante. Et pourtant, les testeurs continuaient de tester manuellement et trouvaient de nombreux bugs ou régressions. C’est bien joli d’avoir une couverture de tests de +60%, mais à quoi servent des tests qui ne détectent pas les anomalies ?

Les deux orateurs, Bruno Boucard et Thomas Pierrain, se présentent comme deux craftmen avec un bon niveau d’expertise en matière de développement et tests. C’est sûr, la présentation va être très pointue. Ils vont surement parler technique, algorithme et enchainer les screenshots de code. Eh bien, pas vraiment.

Le premier orateur commence par nous refaire la biographie de Michel-Ange. Il en en est fan, c’est évident ! Mais quel est le rapport avec le TDD ? C’est très simple. Michel-Ange est un exemple parfait pour démontrer l’efficacité de la règle des 10.000 heures. Cette règle nous garantit qu’on peut tous devenir un expert dans n’importe quel domaine. Il suffit « juste » de s’entraîner pendant 10.000 heures. Bon, je m’accroche et dans 9.999 heures et 30 minutes, je serais comme ça :

Maitre Yoda

Les deux orateurs ne se démontent pas. La preuve, Néo dans Matrix apprend bien le kung fu en quelques secondes grâce à un apprentissage accéléré qui vaut bien 10.000 heures pour un homme normal. Si c’est Néo qui le dit ! Et comment faire lorsqu’on ne vit pas dans la matrice ? Facile, il suffit de pratiquer le « code kata » et le « coding dojo » fréquemment. Les orateurs nous ont ensuite proposé des solutions pour remédier aux 4 critiques souvent faites sur le TDD.

Problème n°1 : Syndrome de la page blanche ou « problème du design émergent »
Cela touche même les meilleurs d’entre nous. Pour cela, on vous conseille de ne pas vous précipiter sur le code afin de faire émerger le sujet et de discuter avec vos collègues. Je suis pour, vive la pause-café ! On peut également appliquer la technique du « should », qui pousse le développeur à identifier ce que le test devrait faire avant de coder.

Problème n°2 : Créer des tests fait ralentir la productivité de l’équipe
C’est bien une remarque de Chef de projet ! Réfléchir est productif. Ce qui n’est pas productif, c’est de taper pour taper, afin de donner l’illusion de ne pas rien faire.

Problème n°3 : Gérer les tests fait ralentir l’équipe
C’est le cas lorsque les tests ont été mal pensés. En effet, il faut tester le comportement et non pas les méthodes.

Problème n°4 : Le TDD est-il efficace ?
On vous répond que oui si vous respectez bien ces deux acronymes : YAGNI (You Ain’t Gonna Need It) & KISS (Keep It Simple Stupid).

J’ai passé un très bon moment. On était loin de la présentation purement technique ou de la présentation vantant les bienfaits de la TDD comme du nouvel accessoire à la mode que nous devons tous avoir ! Les deux orateurs sont des passionnés : ils transmettent leur savoir avec humour et bon sens. Ils donnent une vision réaliste du TDD. Oui c’est fastidieux. Et en plus de réfléchir, on doit s’entraîner encore et encore. Ce n’est ni magique, ni inné. Dommage. Mais avec de l’entraînement et en respectant les bonnes pratiques, c’est efficace. Pour répondre à Martin Fowler qui demande si le TDD est mort, je laisse un autre philosophe des temps modernes lui répondre ceci :

Jean Marc Généreux

Le Lean Kanban, c’est aussi du networking !

J’ai croisé des anciens collègues, nous avons parlé de nos problématiques sur nos projets et cherché des solutions. Nous avons également rêvé ensemble en débriefant sur les précédentes présentations et échangé sur ce qui nous plaît dans notre travail.

En conclusion

Le Lean Kanban France 2015 fut une réelle bouffée d’air, cette journée m’a permise de prendre du recul sur les difficultés liées à mes projets en cours et d’imaginer ce qu’ils pourraient être, à ce que je pourrais mettre en place et apporter à mon équipe. Tout ça pour retrouver le plaisir et la passion de travailler dans le domaine de l’IT !

Share
Marilyn KOL
Marilyn KOL

1679

Leave a Reply

Your email address will not be published. Required fields are marked *