Webcast des MS Techdays 2010

Les webcast des derniers MS techdays sont disponibles depuis quelques semaines. On y retrouve notamment la table ronde à laquelle j'ai participé. Il y avait du beau linge autour de cette table, qui ressemblait d'ailleurs plus à une brochette d'experts étant donnée la configuration des tables :

• Laurent Bossavit, membre du bureau de l'Agile Alliance et Agile France,
• Véronique Rota, ex-Valtech et auteur d'un livre référence sur le management agile,
• d'autres anciens Valtech comme Xavier Warzee, l'animateur Microsoft de cette session, et Jean-Laurent Fabre de Morhlon, team leader chez Vidal,
• des experts de sociétés de conseil, comme Eric Mignot, coach agile chez Pyxis, et Luc Legardeur, fondateur du French Scrum User Group et de Xebia,
• et donc moi, en tant que coach en transformation agile chez Valtech.

Le webcast de la session s'apparente plus à un podcast car seuls les slides de la session sont visibles, slides qui n'étaient là que pour appuyer les changements de sujets. Il faut donc reconnaître les voix des uns et des autres. Cette session fût enrichissante au niveau des sujets abordés et des questions posées. L'agilité reste un paradigme qui soulève encore beaucoup de scepticisme et de blocages. Malgré tout, on sent bien que la révolution est en marche et que la plupart des organisations participantes se demandaient "comment y aller" et non plus "est-ce qu'il faut y aller".

=> Voir le webcast

Suis-je un mauvais coach agile ?

C'est la question que je me suis posé en lisant un n-ième article de blog américain sur le coaching agile avec, en vrac, 4 citations de bouquins faisant "autorité", 3 références à des modèles comportementaux, 9 utilisations de termes japonais, 2 métaphores sur les arts martiaux, et 1 signature prétentieuse. Je me suis senti quelque peu "nanifié" de ne pas connaître la moitié des références exposées.

Car oui, je clame haut et fort mon ignorance:

• je ne connais pas le modèle de Tuckman
• j'ai fait du judo quand j'étais jeune et je ne vois aucune similitude avec le développement informatique
• shu ha ri est un concept vague dont j'essaye de percer le sens lorsque je propose des sujets à des conférences agiles
• Kano est le nom du restaurant en bas de chez moi
• je n'ai jamais réussi à lire un livre sur l'agilité jusqu'au bout; le seul que j'ai terminé concerne le Lean (The Machine That Changed theWorld) et ne parle pas du tout d'informatique

Une telle étendue d'ignorance et de mauvaise volonté devrait me conduire droit à l'échec sur mes missions de coaching agile.

Et pourtant ...

... mes différentes missions de coaching agiles se passent bien et atteignent leur objectif (jusqu'à preuve du contraire). Je vous propose donc mon top 5 de ce que je mets en oeuvre dans mon coaching d'équipe agile (garantie sans termes japonais):

1. pas trop de changement d'un seul coup: ce qui compte c'est l'application des 4 principes agiles, le reste c'est de l'enrobage à distiller au compte-goutte et dont une grande partie relève de l'initiative de l'équipe. Si certaines techniques ne sont pas bien appliquées dès le départ ce n'est pas grave, il faut se concentrer sur les quelques éléments clés qui caractérise une équipe agile. A mon sens ce sont les itérations en time box, les démos avec du logiciel qui fonctionne pour de vrai, et la communication directe. Il y en a bien sûr beaucoup d'autres, mais cela vient progressivement,
2. du pilotage opérationnel: il faut que l'équipe, et plus largement mon client sache où il va et quels sont les mécanismes de gestion d'un projet agile. La période de coaching ne doit pas générer d'effet tunnel. Par exemple, quitte à me brouiller avec des agilistes chevronnés, je fais en sorte que les itérations atteignent leurs objectifs, et surtout la première itération. L'échec est un luxe que se permettront les équipes rompues à l'agilité. Egalement, il est utile d'organiser des comités de pilotage du projet, celui sur lequel intervient l'équipe coachée, à chaque fin d'itération et avec des participants qui vont au delà du PO (typiquement la hierarchie). C'est là qu'on présentera les indicateurs, les projections de budget à terminaison, la variation du périmètre, bref les mécanismes de pilotage. C'est en quelque sorte la démo de la mission de coaching agile.
3. de l'écoute, de l'écoute, de l'écoute, et encore de l'écoute: il me semble très important de prêter une oreille attentive à tout le monde c'est-à-dire bien sûr l'équipe, le Scrum Master, et le Product Owner, mais aussi son chef, les collègues, les utilisateurs, le commanditaire de la mission de coaching, son chef, les instances transverses, bref tous! Je ne jette aucune information ni n'écarte d'un revers de la main les réactions inappropriées. Tout commentaire est bon à prendre, toute réaction a son fondement et cache parfois des informations capitales pour la réussite de la transition vers l'agilité
4. de la communication: expliquer en permanence les principes de l'agilité à toutes les parties prenantes (direction, organisations transverses, équipes métier, contributeurs, prestataires, etc). On s'aperçoit vite que l'équipe coachée est entourée d'un nombre insoupçonné de personnes qui ont un rôle à jouer ou qui influencent d'une façon ou d'une autre le travail de l'équipe
5. de l'empathie: les membres de l'équipe coachée vont traverser un changement parfois très profond de leurs habitudes de travail. Cela apporte son lot d'incertitude, d'angoisse, voire de souffrance dans certains cas. Je ne suis pas là pour torturer mes clients mais pour leur faciliter la tâche, j'essaye de ne jamais l'oublier.

Bon, tout ça pour dire quoi ?

Pour dire que je suis prêt à entendre qu'il faut sans cesse se cultiver pour améliorer ses pratiques, mais il faut pouvoir ... mettre sa culture en pratique!! Je trouve qu'il y a quand même un bonne partie de toute l'agitation autour du coaching agile qui tient de la démonstration mathématique voire parfois de la masturbation intellectuelle, et qui ne sert pas à grand chose concrètement.

Sayonara !
NB: ce message ne s'adresse pas aux bloggeurs pragmatiques qui adressent également tous ces concepts dans leur messages. D'ailleurs, j'envoie mes remerciements à JC qui reste ma première source d'information pour comprendre le baragouinage de certains :)

Dojo TDR @ XP Day France 2009

This is a late feedback on my session:

+ good attendance, room was full but not overcrowded, great :)

? this was my fifth experiment of this type of dojo, we started the first experiment with a colleague last November; I still had high expectations on the output

+ the subject (Blackjack) was an excellent base to work on, thanks to Gojko whom I stole the idea from

+ thanks to the XP Day goodies, I got a much better timer than I used to have for timekeeping

- I proposed the fitnesse wiki to record the tests, not a very efficient tool for authoring, but that's all I had on my laptop

+ the audience was very dynamic trying to help the keyboard holder

? I started the 5mn turns, intentionally choosing a test that was not at the heart of the problem, just to check whether the participants come back to the core topic, they did not, so I'm not sure that was a good idea

- the participants started quite late to identify interesting tests, actually that was half-through the session when I asked them whether the tests roughly illustrated the Blackjack rules

+ towards the end, one participant got rid of FitNesse and grabbed a pencil to draw some tests on the paperboard, that helped a lot to share an understanding on blackjack rules

+ the conclusion that I made to the audience was something like: "if you want to learn about the domain and the requirements, don't pay too much attention to the rules, they're distracting you from the objective"

+ finally, I received very good feedback about the session from the participants, if you attended the workshop and have some more feedback, please let me know

Outils de tests open-source

Les slides de ma présentation au dernier afterwork Valetch sont sur slideshare:

Outils de tests open-source

Qu'avez vous testé aujourdhui ?

C'était aux Valtech Days en Novembre dernier, vous pouvez retrouver la présentation en français et en vidéo sur Valtech TV. J'ai mis la présentation sur slideshare:

Qu'avez vous testé aujourdhui ?

What have you tested today ?

I will be presenting a lightning talk at the Valtech Days 2008 in Paris, the 21st of October.
It will be a "refactored" version of the lightning talk I made at the aa-ftt workshop the 4th of August just before the Agile 2008 conference. There is a low-fi shooting of this talk on google video, thanks to Elisabeth Hendrickson:



One of the attendees also wrote a blog post referring to the talk.

Since then, I went on thinking more and more on how to present these values and the rationale behind them. One of the consultant in Valtech also found a pretty good name for this talk: "What have you tested today ?". I think this question nicely wraps up the 3 values that I emphasize. There is the name of my lightning talk! Come the 21st of October to know more.

The material of the TDR workshop at Agile 2008

I'm posting here the (electronic) material that I created for my workshop at Agile 2008, Test-Driven Requirements: Beyond Tools. Feel free to reuse it to play the game yourself, I just want you to keep me informed of the output.

Game 1:
I created this game after an experiment in which I participated at the University of Linköping (Sweden) back in 1999. I found the concept interesting enough to make a parallel with software engineering. I named the 2 main players "Product Owner" and "Developer" and I added a couple of roles, the User and the Tester, to add a bit more spice to that game and make it closer to software product development process.
To play the game, you need 2 identical sets of wooden blocks, a table, and a splitter.


Here are the instructions of the game:
- Audience instructions
- Players instructions

Game 2:
I completely made up this one (or think so until someone tells me it's an old game they played at Agile 1975 ...). In this game, groups of 3 to 9 persons try to uncover the requirements of a vague specification that a user (one of the group's member) had read just before. The objective is not so much to uncover real requirements or needs, but rather to use tests to explore the needs and formalise a specification. The users don't know anything concrete, so the specification should be elaborated as a result of a group collaboration.


The game starts with a short presentation reminding the audience about tools and techniques for using tests as specification. Then, one user in each group is given a Memo to read to get to know the context of a system on which the group will work. I allow the group to work 20 minutes and then ask them to write the result of their collaboration on a sheet of white paper. I will post soon the output of the workshop (I have to upload a report on the Agile2008 submissions website).