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

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

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).

Agile 2008: Presentation of Examples stage

Here is a podcast where Adam Geras presents the Examples stage of Agile 2008. He talks about my session towards the end of its speech. Thanks Adam.

You will also find podcasted presentations of the other stages here.

Preparing Agile 2008: TDR workshop

Yesterday evening my colleagues and I organized at Valtech office in Paris a rehearsal of my workshop for Agile 2008. This event was open and announced on the XP France web site. My colleagues took this opportunity to videotape the session and we invited a production company to do the same, so hopefully we should post a video abstract in a couple of days on the Valtech website. I would like to thank all the participants that took time to come after the standard office hours. They've been greatly rewarded with pizzas :)
Eric has already posted a summary of the evening (in french).

It was the first time I conducted the second part of the workshop, as I'm already conducting the first part in the TDR courses. This session uncovered lots of interesting points.

About the format and organization first. It lasted approximately 135 mins despite my efforts to shorten some phases, so it is still 45 mins too long. I can to optimize time by writing guiding sheets for the participants so I don't need to explain too much what they're exepected to do, that will also make the instructions clearer. I will also reduce the number of wooden blocks so the first part of the workshop can fit within the expected 30 mins.

Regarding the content I was surprised how unnatural it seems to use tests for exploring needs and formalizing requirements. The participants did use examples in their discussions, but it seems they didn't realize that these examples were already test embryos, so they took note of generic software requirements made after the examples, and then wrote tests from those requirements... Well, exactly the opposite stuff I wanted to see... So I encouraged the groups to work on concrete examples, and start writing tests from those examples.


Then going from examples to concrete tests seemed another uneasy step. I observed that many of the participants proposed to write tables (FIT habits ?) where I felt writing text and progressively maturing a DSL would make more sense and be more efficient for the exercise. As a result, participants were spending lots of time trying to put everything in a couple of tables and thus looking for suitable formats rather than simply writing tests as examples unfold. I also saw the teams progressivelly overwhelmed by the complexity of the requirements and losing track of the basic examples they had discussed at the very beginning of the exercise. They did not want to write tests until they get a sufficient idea of the requirements and they understood their complexity.


This workshop tought me that using tests for exploring needs and specifying software isn't that obvious. We should definitely think of some communication techniques so that teams get some guidance in this field, something like the TDD process applied to requirements (well, we've come a long way, it is the idea of test-driven requirements after all...). TDD does not allow you to write bunch of tests at once and then produce the code, it tells you to do one thing at a time, so you're not overwhelmed by the complexity. What could be the process for TDR ? What about: 1. get an example, 2. write a test, 3. get agreement on that test. We need to think about that and I'm really eager to conduct the workshop at Agile 2008 to check the output.

(Feed)Back from XP Day France 2008

I attended the XP Day France 2008 last week, and also gave a talk on the second day. The conference was a success as they recorded more participants than last year. From my point of view I participated in sessions much more interesting than I expected, and especially enjoyed some enriching workshops.

In the morning of day 1, I attended the workshop on Lean System. That was a role-playing game in which a team had to build 10 paper-shadocks in an assembly line-like mode during rounds of 10 mins. After each round the customer (the workshop leader) would accept or reject the finished units depending on what she found acceptable. The project manager would then calculate the financial results based on the sells (accepted shadocks), consumed commodity (paper sheets), team-member wages, facility (tables), etc. I played the shareholder, not a very demanding role as I just had to sit and wait for the financial results, then look very disappointed as the results were quite bad until the last rounds. Before beginning a new round, the team could only take 1 action to improve the output and increase the overall results. Beside being fun, the workshop actually tought some interesting lessons while it was not really focused on software development:

• first of all, I realized that Lean System is not mainly about removing waste, it is firstly about removing variability among instances of the same steps. This point, though, might not make much sense in software development and this is probably why we talk much more about removing waste in lean software development,
• applying lean system may drive to reduce human resources while increasing productivity and quality. I thought only productivity and quality was the focus while keeping stable resources. The workshop leader therefore stressed that initiating a lean system within an organisation might fail badly if it does not happen in an economically favorable context, because employees will not contribute to a system that might lead to removing their job.

In the afternoon of day 1, I attended the Lightning Talks led by my colleague Yannick. I also made a try at the XP laboratory but soon left the session as it turned too technical to me. What I experienced there was indeed very weird: at the beginning of the session, the organizers explained briefly what was realized thus far and what was the stories they proposed to make in the first iteration of the session. They then asked whether the participants were comitted to delivering these stories by the end of the 10 mins iteration. And guess what, nobody said no ! None of us had a clear idea of the existing design, code quality, or past problems, but we all comitted to deliver the stories. Even more striking is the fact that everyone but me then rushed to the available laptop PC to dig in the code and start programming. Well, I left the session soon after as I'm quite unable to undertsand or program a line of JAVA. I did not feel like that was a great XP application. I however had the occasion to discuss this brief experience with the workshop oragnizers, François Beauregard and Eric Mignot from Pyxis, and it confirmed what I felt: the organizers let the team made some mistakes so that they could learn the XP values. They also were very surprised that no one, whatever the sessions, refused the comittment on the proposed stories having no idea of the design and problems. This is even more striking knowing that this laboratory did not have any financial stakes and that most of the participants are not beginners in the Agile world. That makes me think the way is still long until we master the Agile values and apply them naturally.

Day 1 ended up with a good dinner. I had the occasion to discuss extensively with an employee of Parkeon, especially on their use of FitNesse. I now have better examples to share if I encounter again the objection that FitNesse and TDR techniques are not suited to embeded software (objections that I often hear when I'm teaching the TDR course).

On day 2 I opened the day with my talk on Test-driven Requirements, while 2 of my colleagues also made a presentation (Romain on continuous integration and Nathalie on contracts for agile projects).

I then attended a very enriching workshop about Leadership. The principle was simple, the participants had to build structures with Lego blocks. We run three such sessions, each with a different type of leadership. The first session was driven by 2 leaders with a commanding type of management, the second had no leader and the team built a church in a self-organizing fashion, and the third had 2 coaching leaders (I was one). A global restrospective at the end gave us the opportunity to discuss the characteristics of a good leader and what they missed to do in the exercise. Beyond the lessons that this workshop was supposed to bring about, I realized something more after the retrospective: when there is a leader, everyone holds him responsible for the failure or success of the exercise, on the other hand, when there is no leader, everyone tries to identify what was good and bad with herself or himself. In brief, we are naturally feeling responsible when there is no designated leader while we naturally shift all the responsibility on the leader's shoulders when there is one. What this workshop tells to me is: if you're a leader, expectations will be high on you whatever the type of management you're applying, so you'd better succeed :)

Finally I attended a presentation on practicing the conflict. The presenters made their talk dressed in kimonos and played small funny scenes to illustrate their points. Briefly speaking it was about using an aikido-based technique to master a conflict and not to avoid it. Beyond these techniques, they stated that conflict is a mandatory step towards successful teams, argueing that conflicts can bring about better solutions. Although I understand and share some of their points, I still cannot consider that the conflict is a must have for successful teams. I rather think that confrontation is a must. Sometimes confrontations turn into conflict so we indeed need techniques to master conflicts but I don't see them as a healthy step toward sucess.

Before leaving, I spent some time discussing with the Pyxis guys and getting a demo of Greenpepper (great tool!).

That was my experience of the XP Day 2008 !

Agile 2008

My session proposal for Agile2008, the world conference about agile software development, has been officially selected ! This is a great news and means I will be flying to Toronto beginning of August to attend this exciting event. I'm scheduled tuesday the 5th at 10.45 AM, I will therefore have the pleasure to kick off the Conference sessions just after the keynote (monday is reserved to research topics and icebreaker). I now have to prepare the details of my session and make sure I can get the material I need to run the workshop smoothly and make it a successful experience for the participants. I will be posting some updates on my preparation as it comes.