The French translation of Hudson is a contribution I have made to the project. The work is complete for the core part of Hudson, and I consider it stable, though many bits are not internationalized, hence appear in English.

What can you do if you want to help?

• visit the wiki page for the French translation: it provides the latest status of the effort
• report typos, alternative translations, anything that can enhance the current translation. Do this on the above-mentioned wiki page (an email will be sent to me automatically), or get in touch with me directly (via a comment to this post, for example)
• if you are a contributor to Hudson, join the internationalization effort
• translate the plugins; I have hardly worked on any plugin at all (except the Fit plugin, which I have written myself). This is the area that needs most work.
• demonstrate Hudson in French to your French-speaking colleagues! for this, simply change the preferred language in your browser to French
• spread the word about Hudson!

Generally, once committed, enhancements to Hudson are released within a couple of days. So anything you contribute will be quickly visible.

I am looking forward to hear from you! And many thanks for your time and efforts.

I first wrote the title of this post in the form “how small should the stories be?”, leading to the apparently obvious answer: “as small as possible”. It is in fact slightly more complex.

Let’s assume here that all your stories are dimensioned using story points. I personally like using “story points” for estimating features, as opposed to “ideal engineering time”, but this is a debate for another time. Let’s just start with story points.

If it all goes according to plan, you should have a whole range of stories, with sizes going from 1 to 21 (or 40 & 100 when you want to make clear that some stories are really big and need to be detailed more in the future). Let’s further assume that you know your current velocity (if this is your first sprint, Mike Cohn recommends either doing rough estimations in hours, or just let the team loose and see the results at the end of the sprint — see his book Agile Estimating & Planning for more on this).

Simply put, you want to be in a position to fit “many” stories into a single iteration.

Having “many” stories is important, because the more you have, the less risk you carry. Suppose that you have only 3. If things go just a little bit wrong, then you’ll miss your Sprint goals by a third (remember, you do not demonstrate or release partially implemented features, right? and testing is part of the implementation effort, right?). Missing objectives by 33% is a lot in the agile world. You appear to have done badly, despite the fact that you still might have complete a significant portion of the remaining code. Even if you have done 95% of the tasks, you still have only 66% of the features — supposing that you tackled the three features in order of priority. Yes, you will probably complete the remaining 33% in the following iteration, and more. But still, your client only got 66% of the features at the date you agreed on. Plus, your velocity will vary greatly between iterations, giving an impression of unevenness and unreliability.

So the strategy is simply to split your features into smaller functional chunks to get closer to “95% technical tasks implemented = 95% features implemented”. My rule of thumb is to aim for 10 features. Some will be bigger than others, but all will be rather small.
In practice, this probably mean that you have a mix of features of size 1, 2 and 3. I might accept one size 5-story occasionally, but I’d keep an eye on it while the iteration is going.

Interestingly, this means that velocity for most of the teams using that strategy will be between 10 and 50 story points per iteration. Reaching 50 points or implementing more than 20 distinct features might be a sign that you are ready to try shorter iterations.

Finally, note that this is, as always, only a step in the never-ending quest to Agile nirvana. Once you’re confortable with having many small features, the next level, besides shorter iterations, could be to force all features in an iteration to be of size 1. That would be a nice improvement. “Our velocity is 12″ would always mean “we are implementing 12 features”. Also, it’d be much easier to select features during the Sprint Planning meeting. I wonder if someone has already been that far.

A journalist from Journal Du Net interviewed me a couple of weeks ago on the tools and (agile) practices we use at Valtech.

All the ideas are there, but I wished the journalist had not literally transcribed my talk. You might also want to check out this version, automatically translated by Google. Rather awful to read, but the content is there.

That’s what you get when you spend several days polishing a post. Unlike <a href=”http://ericlefevre.net/wordpress/2008/06/02/cruisecontrol-is-still-the-bigger-player-hudson-is-growing/”>what I suggested in my previous post from today</a>, Sun does seem to take action regarding Hudson. <a href=”http://weblogs.java.net/blog/kohsuke/”>Kohsuke Kawaguchi</a>, <a href=”https://hudson.dev.java.net/”>Hudson</a> creator, has just been <a href=”http://weblogs.java.net/blog/kohsuke/archive/2008/05/ill_be_spending.html”>promoted to working on Hudson full-time</a>. I’m jealous

Congratulations, Kohsuke! You deserve it.

I thought it’d be interesting to look at some download statistics for Hudson and CruiseControl, probably the 2 OpenSource CI tools with the most mindshare currently.

Want to know more about CruiseControl, Hudson, and other CI tools? Meet the creators, contributers and users at the next CITCON conference in Melbourne, June 27th & 28th. Cannot make it to Melbourne? Then CITCON Amsterdam, October 3 & 4 is for you (I know I‘ll be there). Or CITCON Minneapolis, April 17 & 18, 2009.

First, a warning: these data are not reliable. The sources have several disclaimers, so please take them with an healthy pinch of salt. Also, the oldest data for Hudson were from the beginning of the year, while those for CruiseControl were not available with the same details for all periods of time. This explains why the two graphs below do not span the same periods of time.

Those stats do not include plugins for Hudson nor CruiseControl.

The weekly downloads are interesting because the are made of constant chunks of 7 days. This graph, spanning only 2 months, suggests that CruiseControl has 2 to 3 times the number of downloads that Hudson has. However, its lead is getting smaller.

The monthly downloads data are available from the beginning of year 2008 which is not bad. However, keep in mind that all months do not have the same number of days (I considered dividing by the number of days per month, but then I’d also have to control for the number of WE days in a month, which is too hard for me). The trend is even clearer than for the monthly graph: the CC stats hardly make any increase, while Hudson gains almost 50% more downloads.

It is tempting to conclude that CruiseControl is losing its lead to Hudson. However, you need to take in account a few more facts:

• Hudson has 2 or 3 releases per week, prompting many fans like me to download it very often, increasing artificially the popularity of the tool. CruiseControl has around 4 releases a year, making it much more stable (it also means that the releases contain much bigger changes). I speculate that recent Hudson users will be less tempted to update to the very last version as often as older users.
• Hudson is still hot and new, while CruiseControl is old news. A number of users want to be the first to talk about it, which explains why it has a disproportionate number of fans in some conferences. The novelty effect will decline in time.
• CruiseControl has a strong organization that keeps putting more money behind it, while Hudson is still very much controlled by its creator; Kohsuke’s employer has yet to define a clearer strategy for it — if they ever do so. So it is still very much possible for CruiseControl to eventually catch up technologically with Hudson.
• The statistics for CruiseControl only take in account CruiseControl Java. The .NET and Ruby versions, though distinct, add to the mindshare of the tool.

The statistics for CruiseControl downloads are available here, while those for Hudson are there.

In preparation to our holiday trip in Indonesia planned for August, I’ve taken to read stories and legends about Hinduism and Buddhism (though a Muslim country for 90% of the population, Indonesia is the host of Borobudur, the largest Buddhist temple in the world). The legends I’ve been reading contain striking similarities between Buddhism and the Toyota Way, which I have also recently read about. Indeed, those similarities are striking.

Go and see for yourself

In one of the stories, a wise lion (the Buddha, obviously) is the only one not to panic when hearing about the end of the world. He goes himself physically to the place where the rumor comes from to see that all the turmoil was caused by an apple falling near a rabbit. This is directly reminiscent of Genchi Genbutsu, or “Go and see for yourself”, one of the 14 principles in Toyota Way. It has also been quoted in the Lean Soft. Dev. books by Mary & Tom Poppendieck.

Change and continuous improvement

In Buddhism, some say “it is all about change” or “the only permanent thing is that everything changes all the time” (I hope I’m getting this right); this is called Anicca. It may sound a bit funny to most people, but Rebirth can be very well considered an evaluation of the progress you made (or didn’t make) during your previous life. A wise person should take this as an opportunity to reflect and find ways to get better next time. In the case of Toyota, this corresponds to at least three (!) of the principles:

• “Create a continuous process flow to bring problems to the surface”
• “Standardized tasks and processes are the foundation for continuous improvement and employee empowerment”
• “Become a learning organization through relentless reflection (hansei) and continuous improvement (kaizen).”

Long-term view

In the Toyota Way, the very first principle is “Base your management decisions on a long-term philosophy, even at the expense of short-term financial goals.” With Buddhism, though short-term is important, long-term is something that a trained person should be able to perceive: “We cannot see the long-term effect of karma, but the Buddha and His prominent disciples who have developed their minds are able to perceive directly the long-term effects.”

Self-reliance

Buddhism did a lot to make clear we should count firstly on ourselves. It generally remains silent on the presence of a higher-being. There is nothing that implies our lives are deterministic, so we can, and we should rely on ourselves for making progress. Similarly, one of Toyota’s principles is empowerment of people already in the company. “Standardized tasks and processes are the foundation for continuous improvement and employee empowerment.” While there are still managers in the company, the employees themselves are the ones that help make real progress. With Lean, Scrum and Crystal, it is regularly explain that People are the First-Order Effect, and that process should mostly help them work, as opposed to tell them what to do.

Is Buddhism a religion?

Buddhism was not originally conceived as a religion. You can have your own religion in addition to it — though it is by no means necessary. Still, most people would consider Buddhism a full-fledged religion, and certainly most actual variant of Buddhism really religions. Similarly, agile methods such as Lean Soft. Dev. and Scrum do not brand themselves are methodologies, but rather as frameworks. You are supposed to build you own, specific methodology within those frameworks, but they certainly do not tell you all you need. Still, most observers (and many practitioners) think that they are, indeed, real methodologies. And it is arguable that some agile methodologies such as XP certainly give enough details to be considered real methodologies.

Final words

It is very tempting to conclude that Toyota Way and Lean Manufacturing could only have been popular in Japan, a country were most people would consider themselves Buddhists. I won’t go that way, as Japan is certainly not the only Buddhist country (China and Korea come to mind). And also because it was originally an American, W. Edwards Deming, that provided Toyota with the theory of what later because the Toyota Production System. Still, a fact is that Toyota Way and Lean was created in Japan. Maybe the cultural context made it easier.

Cédric Dhénin from TV4IT has an interview of me talking about TDD (in French).

Considering this was the first time for me, and that we had to do it all in one take (no editing), I am rather happy with the outcome. There are a couple of minor things I forgot to mention (only the interviewer had notes), but all in all, I managed to say almost all I wanted in the 5 minutes I got. Anyway, this was rather high-level; the target audience for TV4IT is mostly CIOs and project managers.

This Monday 5 and Tuesday 6 of May 2008, I have been to my first XP Day(s, it actually lasts 2 days) in Paris, an event organized by the association XP France; here are my impressions:

At 8:30, slowly, every guest gets his ID tag, and a breakfast is offered, were discovering the schedule of the days to come: the event is divided into 4 rooms, and each day is divided into 4 1 hour and a half sessions (but a session can last all day long or also half a day); all sessions are in French language.
Many subjects are present, the advantage is that you are sure to find something interesting; on the other hand, if 2 appetizing meetings take place at the same time, you have to choose.
Then, at 9 o’clock, were about 150 people (I think) and we are asked to go downstairs, to attend the introduction meeting where the organizers of the event introduce themselves (and also ask people to, if they can, contribute for the next XP days) and the following XP meetings (Agile Tour, round France, and Agile Open, where attendees will be able to turn into speakers); finally, the speakers of the day introduce what they will be talking about during the sessions they will present.
I chose to be present at the XP laboratory, presented by 2 folks working at Pyxis (a Quebec based company responsible, among others, of Green Pepper).
The session last all day long (but you were free to leave or get back when you want) and invites people to work on a refactoring of the Miles card game (“1000 Bornes” in French), called XtremeMiles.
People immediately configure their laptop to get up and coding:
The thing is, the speakers turn themselves into the “Client” (or the product owner, because XtremeMiles is a Scrum project) and the “Scrum Master”, and they ask us, the developers, to adopt a Test Driven Development procedure (we write the tests, with JUnits, before we code).
But the main aspect developed is that were organized in a Scrum project (it was actually the first time I experienced this kind of Agile organization).
So to sum up the procedure :
First, we have a meeting with the Scrum master and the product Owner to ask questions (5mn), to agree on engagement (5mn for the team to choose the cards proposed by the product owner, which contain stories, tracing functionalities) and for the sprint backlog (5mn);
Then, the sprint lasts 3 days for each iteration (a day in this game lasts 20 minutes, divided into 2 minutes of stand up meeting, where developers tell the Scrum Master what they have done, the problems they have encountered and what they hare going to achieve; and 18 minutes of work)
Finally, it’s time to show the demo where the developers and the Scrum Master present to the client what they have achieved during the iteration

To code, we used eclipse with subclipse and JUnit, the speakers prepared a Bamboo (continuous integration) to test if a commit would break the build (we were under pressure !)

I attended this session 3 hours (2 iterations) and it was quite fun and very interesting : we have been able to witness problems of communication between teams, the way an agile project can rapidly react, etc…
This session was so popular, the organization decided to make it last one day more !

The afternoon, I was present at the “Sujets Eclairs” (lightening talks) session; where anyone in the room can present a subject and explain it in 10 minutes.(usually people who talk during lightening talks are not familiar with public presentations; moreover subjects presented are usually not prepared)
Many topics were proposed, most of them were about project management and agility.(which was nice actually)
The first day finished with some words from the sponsors, among them, Valtech, my employer ! (and also an excellent dinner !)

With Pipes, I think Yahoo! has a really interesting and powerful solution. Yesterday, I did a quick demo to my colleagues during an internal Lightning Talks session showing how they could tune their blog feeds in order to integrate better in our corporate planet blog (still under development).

For this, the programming is really simple. In the case of my own blog, I only needed to filter out posts marked with the ‘personal’ category. The pipe looks like this (I’m not providing a link to the original pipe, because there is a good chance it will get changed by the time you access it):

Simple, or what?

Notice the list of available components on the left-hand side, with documentation on the lower-left panel. Also, the ‘debug’ panel on the bottom of the page shows the output of a particular element. Really convenient.

I have also used Yahoo! Pipes to aggregate several blogs coming from my colleagues, the end plan being that to show them on a common page. Aggregating several blogs is more challenging, because you do not control all aspects of a feed. So you need to do slightly more advanced processing.
In the case of our blog, I had to:

• add an author element to some feeds that didn’t have one
• remove duplicate posts
• truncate descriptions, as some were taking way too much space on the final page
• some feeds had elements containing similar values (author, typically), but with different name, so I copy them to the appropriate element
• do various minor clean-ups

Obviously, the resulting pipe is more complex. Still readable, though:

All in all, I am very impressed with the technology. I’m not going to say that anyone can use it, even non-programmers, but it is certainly open to many more users than standard programming languages.

Microsoft seems to have a competing technology with Popfly. One difference, though, is that it requires the installation of the Silverlight runtime (and a Passport login — I used to have one, but lost it years ago), which makes it a bit more clunky to work with. Yahoo! Pipes only requires a Javascript-enabled browser. A casual look at the Popfly homepage suggests that most usages of the technology are mostly made by people already using MS products (many implementations for the Zune, for example). However, Google Trends suggests that Yahoo! Pipes and MS Popfly actually have a similar mindshare.

Another service that is competing with Yahoo! Pipes is Feedburner. More more limited, though. For example, if the ‘author’ element is not provided, you have the option to provide a value. But it must be hard-coded (impossible to get it from another element in the feed, for example). Feedburner has a feature called Feedburner Networks that would have been of use for us, but it seems to be in beta, and only those who join the beta program last year that play with it.

In fact, Feedburner is not even trying to compete seriously with Yahoo! Pipes. Their big thing is marketing: they provide a good number of tools to compute statistics and traffic information. This is rather nice. My main concern is that they have been acquired by Google a year ago, and it seems that few new features have been created since then. I’m sure they are working on integrating with Google Analytics, but where’s the meat?

That said, I am at least using it to clean-up a feed that Yahoo! Pipes failed to read. So everyone can play nicely together, you see!

Anyway, go and check out Yahoo! Pipes. Really impressive stuff.

Those of you who came to CITCON London 2006 might remember the talk by Jeffrey of the same name (I have a couple of notes from back then, also see the entry for Agile 2007 conference and comments on Alistair Cockburn’s idea — Jeffrey & Alistair collaborated on that talk). This was also discussed at CITCON Brussels last year on a session arranged by Douglas Squirrel: Karma for Continuous Integration.

Essentially, the idea is that by giving token gifts to team members, you can get them to fundamentally change their working habits.

Well, redsolo has implemented a plugin for Hudson that does pretty much what Squirrel was suggesting: allocate points depending on what the developers are doing. The points are awarded or removed on build breaks, tests passing or failing, and on build successes.

Now, if I remember the discussion from CITCON Brussels correctly, the conclusion was that such a tool did sound like over-engineering a social problem. That was worth trying, so I asked for help on the CITCON Mailing List. Alexander Snaps was kind enough to give it a try with his team.

The outcome is that one of the developers was quick to point out that the point allocation was not entirely fair. This is an interesting result, because it shows that the points system works: developers do care (at least in the short run) about things as trivial as points. On the other hand, of course, it shows, again and again, that the devil is in the details: it is close to impossible to allocate points in a perfect way. You will always find another special case with a different point allocation pattern. Now, you could spend a long time trying to implement them all. But that this is really over-engineering…

Best would be to let the developers decide for themselves. Give them simple rules (one point per new successful test!) and let them request the point by themselves. They will figure out the details.