Eric Lefevre-Ardant on Java & Agile

I am giving a 3-day TDD training session at Valtech Training premises, from Monday, October 6th. I’ll introduce a Coding Dojo, like we did in the TDD training last week.

I have spent quite some time translating the titles of the presentations at Valtech Days for Jeff McKenna. I thought it would be a good idea to give you the information too!

In the past three days, I have taught Test-Driven Development to a group of Java developers in Brittany. I thought it was a good idea to arrange an inpromptu Coding Dojo. That contained a moderate risk, as all dojos I knew of were attented by volunteers.

It turned out very well. Though one or two participants managed to check their emails at some point during the session, most were paying attention at all times.

A couple of things to remember for future dojos:

• In the past, I have usually attented dojos were either everyone was in front of a computer (either coding or co-piloting), or a single pair was coding in front of the others. After watching Dave Nicolette and Ryan Hoegg facilitate a dojo where all got to code in front of the public at Agile 2008, I thought this was a good way to get participants to do their best, plus let others to read code with a watchful eye.
• A participant mentionned that the exercice helped him realize that names for test methods were very important. Yay!
• For first-timers, always start with a very, very simple exercice. We did the dictionary kata (given a collection of words, find all words in a String that are not in the collection). We managed to complete it satisfactorily in 2x 30 minutes.
• We did our best to run through the code Test First, writing the tests with as little prior thinking as possible. That said, one participant suggested that pairs should talk a little before doing so, in order to get the pair to bond better. Sounds like a good suggestion, though it would probably require more time than what we had available.

All in all, I am happy with the outcome. We should include it in our course curriculum.

Yesterday, I went to a presentation of Groovy at Paris JUG by Guillaume Laforge. One of his points was that Groovy is well-suited for designing DSLs - Domain Specific Languages. I think he said something along the lines of “with just a few commas here and there, you can get business-facing people to write the business rules themselves”.

Well, I disagree with that. While I am sure that some of these business guys are interested enough to spend time learning the little quirks of the resulting DSL, I expect most not to bother with it. It would be totally better if, instead of starting with a language and its constraints, you could start with what the business guys would want, and then design the language. Which is of course no small feat, and might be feasible only with a lexer/parser-type tool.

However, I think that Groovy is well adapted to what Martin Fowler recommends: first, make the DSL easy to read. From his recent post:

“You get most of the benefit of business facing DSLs by doing enough to allow business people to be able to read the rules. They can then review them for accuracy, talk about them with the developers and draft changes for developers to implement properly. Getting DSLs to be business readable is far less effort than business writable, but yields most of the benefits.”

The commas and other details are OK when reading a DSL, even for non-programmer people. This seems to be like a very pragmatic, valid approach.

In truth, this was visible in one of the examples he gave involving a health organization, fortunately documented on Guillaume’s blog:. Here is how it looked like (excerpt from this post):

regimen.take drug: CQ, qty: 2, at: 0.h

Easy to write for a developer. Easy to read for a business person.

Like everyone else, we are interested in new framework to design richer web interfaces, usually known as RIA - Rich Internet Applications.

Most people will agree that there are three big contenders, but they all have limitations:

Too many choices, by Orin Optiglot

• GWT, though my favorite as a long time Java developer, is still limited in the quality of interfaces it produces; it requires the use of third-party libraries, but there are not that many of them, and some have been tainted by changes in their licenses. Also, Google does not seem to put that much energy into it; in many ways, it still seems to be a one-man operation. However, my guess is that it is adequate to design classic interfaces, similar to the one designed in AWT/Swing/SWT.
• Flex might the strongest contender to many, as they have all Adobe’s might behind them (unlike GWT). But it is clearly a descendant of Flash and as such might appeal most directly to web developers (as opposed to classic Java developers). However, they did make a lot of efforts to get closer to the Java crowd. My feeling on this one is that people like me might be good at working out the server part, but should still leave the UI part to web developers.
• JavaFX might seem like an obvious choice for a Java developer, but it is still too young (1.0 to be released this fall) and does not have that much mindshare yet; it also requires a plugin to be installed. That said, at least one of my colleagues is very enthusiastic about it.

This list wouldn’t in fact be complete if I didn’t also mention:

• SilverLight, which is really the answer from Microsoft to Flex. I don’t have a strong opinion on it, apart from the fact that it also requires a plugin on the browser, which is a serious disadvantage (just like with JavaFX). Many people upgrade to Flex while upgrading their Flash plugin, which they have to do anyway, now that there are so many Flash animations. Silverlight has no such immediate upgrade path.

All of those frameworks are good at avoiding the complexity of writing JavaScript code, either by writing it for you (GWT) or by using a specific engine on the browser (Flex, Java FX, SilverLight), which has the drawback of requiring the installation of a plugin (which might not even exist for some systems).

A relative of mine who is working at a small software house however points me to

• JQuery. The assumption here is that it is vain to work around JavaScript; it aims at making it easier to code JS. So you still have a good chance to stumble on the many difficulties of writing JS. On the other hand, you do get to have a much better control of the final code. At any rate, JQuery does seem to be getting some buzz these days, including from my colleagues.

So, which framework should we/you choose? I think neither has a clear lead so far. So you might want to apply a set-based strategy, as recommended in Lean Software Development. Meaning that, when in doubt, implement all plausible strategies, and decide later which one to standardize on, once the dust settles. In fact, it is very possible that several of them will co-exist, or even integrate with each others.

If you do want to limit the set of strategies, my personal choice would be those three:

• GWT
• Flex
• JQuery

Yesterday evening, we attended a concert at Salle Pleyel, the most prestigious French venue for classical music.
The host was Ravi Shankar, one of the masters of classical Hindustani music in general, and of sitar in particular.

It was not really a concert in fact. Rather a talk about classical Indian music, with a little bit of demonstration done by the accompanying musicians (Shankar directed the effort, almost entirely improvised). Though I was disappointed not to hear the master playing, hearing him talk was a unique event. Plus, I didn’t know much about Indian music (I didn’t even know there was another style than Hindustani, called Carnatic music, most specific to South India), so it was all new information to me.

Two things came to me mind during his talk:

• how lucky the music world is to have such teachers. It is true that spectators were part of an elite (people that had heard about Indian music - also, the Salle Pleyel is not exactly for rap music). But still, many of them did not know much about the details of Indian music.

Though Shankar might be one of the most respected, he is not the only one. Others such as Wynton Marsalis have been known to try teach music to the average laymen.
Wouldn’t it be nice to have equivalent figures in the IT industry? Imaging Jerry Weinberg or Fred Brooks touring secondary schools, explaining why software made them tick, while dispensing information on how these things things work.

• responding to a question regarding modernity and tradition, Shankar insisted that “to break the rules, you need to know the rules” and that creation of new, beautiful things have been done by masters over long periods of time

There is a parallel with the concept of Shu Ha Ri, frequently refered to in software/agile development. All masters, whatever the domain, insist that we need to follow the rules, the basics, without questioning them too much, before attempting to break free and innovate. So why are we so quick to disregard them (”oh, this part is not for me”, “pair programming won’t work here”) and do things our own way? In software, as in music, modesty would go a long way.

Many people have asked me to talk about the A4 Reports that I have introduced on one of our projects. I’ve postponed this for a look time, but I finally got around to do it.

The idea came from the book Toyota Way, by Jeffrey Liker. At the beginning of the book, the author warns the reader against a classic trap: after reading about the success met by Toyota, many want to implement their practices verbatim. Well, my philosophy is that, if I got only one useful practice from the book, then it was worth paying for ;-)

So anyway, the author is telling about the fact that Toyota employees do “A3 Reports”. The idea is that, when there is a problem, after careful thinking, the people in charge produce a report that fit on an A3 page. The reason for this constraint is that 1) is it quick to read, 2) it can be faxed around the company with the fax machines they have.

Another thing is that they tell about the problem and the solution using Plan-Do-Check-Act (PDCA). Which means that their reports typically contain:

• a description of the problem
• an overview of the possible solutions, including options that were later discarded
• a description of the implementation of the solution on a limited scale (Plan & Do)
• a description of what needs to be monitored, and milestones (Check)
• if the solution is proving a success, a description of the implementation company-wide (Act)

I was personally attracted to the reports, because they force the writer to keep the information concise, though readable. Graphs were good too, as long as they make the contents clearer to the reader.

My personal problem was that, as a ScrumMaster, I have to produce reports every time we complete an iteration. The reports are boring to write, probably boring to read, and they were getting longer as the various stakeholders regularly demanded that I add more information. Other metrics that had to be maintained included productivity, progress on project, etc. I felt that these metrics were not very useful and I had also been getting into arguments with my boss’ boss, especially after a steering committee where it had become clear that I couldn’t make the situation easily understandable to our clients, even with an Excel document containing 6 sheets. So I was feeling some pressure to show goodwill, and to produce something that was actually useful.

One day, my direct boss demanded that I produce not only my usual textual report (generally 2-page long), but also a 10-slide PowerPoint presentation. I was underwhelmed, since I already felt my report was not that useful. I got her, though, to agree that, in addition to what she wanted, it’d be worth trying those shorter reports.

I set myself the following constraints:

• must fit on a single A4 sheet, as this was the only format of paper supported by our printers
• character size must stay at 12 points for normal text; text that was part of graphs just had to be “as readable as I could make it”

The result for the first Sprint to have an A4 report is the following (in French):

Things of note:

• the 3 columns; they are the key to fit as much text as possible when you have many bullet points
• the charts, especially the burndown chart. This was the first time I managed to show the burndown chart in a readable fashion in a report to people external to the team.
• the content, which is made largely by the information gathered during the iteration retrospective

When my boss saw this report, she was delighted. It became the main document discussed during steering committees between the various stakeholders, including the CEO of the company. I also sticked it to the walls of the development room, in full colors.

In later iterations, I refined the report a bit, but it stayed largely the same. For a few iterations, I had a tendency to change the charts, depending on the situation (for example, if speed of development was an issue, I’d add a chart showing the number of actual work days per iteration). I have found that it was not as necessary in later iterations. Probably a good thing, as I would not be able to gather all the data necessary.

Here is how it looked in a recent iteration (in French again, so it might be hard to figure out what each box is for):

How I build the report:

• The report is built using Excel. Some charts come from external sources, such as the burndown chart which I extract from the Google Spreadsheet-based Sprint Backlog; an issue is that, being images, they are hard to redimension. Other charts come from separate Excel files, which is a bit annoying as Excel suggests pulling data from the other Excel files every time I open the report. Finally, some charts are made from data that are hard-coded in the same Excel file, such as velocity and code coverage.
• A lot of information is actually coming from the Sprint Retrospective. I can prepare a few things before the retrospective (mostly the charts) but much of the data is mined from what was learned during the retropective.
• I spend quite some time adjusting the boxes on the sheet. The best way I’ve found is to use drawing features from Excel that let you perfectly align or center elements together. Still, it takes significant time to clean up at the end.

For your information, here is a list of the noxes used in the last report. You will want to adapt this to your needs:

• Sprint Number & Dates
• Implemented Features
• Features that Were Not Implemented
• Important Facts from the Sprint
• Burndown Chart; this is now coming from a Google Spreadsheet ;-)
• Statistics on bugs
• Things We Could Improve Upon
• Things We Are Happy About
• Actions For Next Sprint
• Project Trends
• Velocity
• Overall Progress on Project
• Overall Bug Statistics
• Code Coverage By Tests

I hope all this will help. Let me know your improvements on my design!

With Agile 2008 just around the corner, superlatives abound: “largest Agile conference in the world“, “premier international conference in agile development“, “a production team of highly respected Agile experts“, “spans the whole spectrum of agile practice“.

Participating companies are also guilty of that.

One such is SolutionIQ, who boasts “more speakers than any other services organization in attendance“. I have counted 9 speakers and 9 presentations on their page.

Well, at Valtech, we have “only” 8 presenters, plus one organizer (yours truly): Greg Hutchings, Gilles Mantel, Dave Nicolette, Ryan Hoegg, Mark Smith, Andrew Rendell, Alan Goerner and Tim Walker. But they will host a total of 12 presentations:

• Greg Hutchings: Distributed agile teams and alternative contractual forms: what works best?
• Greg Hutchings: Contractualisation des projets Agiles
• Gilles Mantel: Test-Driven Requirements - Beyond Tools
• Tim Walker: Scrum Accelerator: The Game
• Dave Nicolette: Effective Pairing: The Good, the Bad, and the Ugly
• Dave Nicolette Manager’s Introduction to TDD, with Karl Scotland
• Dave Nicolette: Overcoming Resistance to Change, with Lasse Koskela
• Dave Nicolette and Ryan Hoegg Advanced TDD Randori & Fishbowl
• Mark Smith: The use of Ritual in Agile currently and identifying improving ways to harness the power of ritual
• Andrew Rendell: Effective and Pragmatic Test Driven Development
• Alan Goerner: The Tail and the Dog: Aligning Governance with Agile Project Management
• Alan Goerner: The Aikido of Agile Project Metrics

So, there! ;-)

Only 3 weeks to go before Agile 2008, the main agile conference. I am very excited, as Laurent Bossavit has kindly invited me to join him in organizing the Breaking Acts (BA) track for the conference. Also, many colleagues of mine at Valtech, between 15 and 20 (it is difficult to keep count!) will be presenting sessions. More on that later — for now, I want to tell you about my favorite sessions at Breaking Acts.

(more…)

Just from this morning, on the Lean Development mailing list.

Mary Poppendieck:

The problem with roles – ANY roles – is that they tend to become a laundry list of stuff a person is expected to do, instead of a checklist that a team is responsible for looking into.

(more…)

I am proud to announce the availability of Planet Valtech, our syndication page for blogs written by my fellow consultants.

This site aggregates mostly blogs from consultants at Valtech France. However, I have also added Dave Nicolette’s (from Valtech US), as well as the official blogs from Valtech France, Valtech Germany and Valtech US. Many posts are in French, but roughly every other post is in English.

The site is nothing special, so you’ll probably want to subscribe to the consolidated RSS feed.

Not happy with all RSS goodness? well, you can complain to me, I am waiting for you ;-)

I am looking the latest version of Weblogic as a replacement for our aging Weblogic 8.1.4 installation.

I first downloaded Weblogic Server 10.3 Technology Preview, anticipating that we would take a while before actually deploying it, and that BEA who come soon with the final version. So far, so good.

Then, just yesterday, I heard that Oracle had released a version of Weblogic, the first since they acquires BEA back in January (April, if you count the approval of the European Commission). I thought it was a good time to upgrade to the latest stable version.

Well, surprise, surprise. For a start, the main Weblogic page on Oracle’s site does not mention a version number. If you reach the download page, it mentions a ‘version 10.0 MP1′. I thought it was a weird numbering system (after all, it should have been 10.3 final, or at least 10.2, which, as I gather, was released in April 2008), reminiscent of Sun’s.

Alas, when I tried to install, the installer clearly stated it was really version 10.0, and only the BEA name appeared (the administration console also has no mention of the Oracle name).

Clearly, not only they had failed to rebrand even the installer, but they managed to released an obsolete version. This is not reassuring.

As a side note, the left-hand panel on the Weblogic console 10.3 TP (I didn’t reached the point where I could play with the console with Oracle Weblogic 10.0 MP1) does not seem to work with Firefox 3 (it is not clickable). It works fine with FF 2 and IE 6, though.

This is starting to seem like a lot of small problems that could have been avoided.

Update (16/07/08): there never was a version 10.2, nor a 10.1, for Weblogic Server. I got mixed-up with Weblogic Portal. So the update on v10.0 is 10.3. So my anger was partly misplaced. Of course, a consistent numbering system would have helped…

Cobertura and Maven: There are TWO important things to do. Then, we’ll see about integrating Cobertura and Hudson.
(more…)

I have originally had a look at Scrum and XP From the Trenches around 2 years ago, I think. It seemed to be good, but too long, so I barely scrape the surface.
Recently, I have had a longer look into it, and there is now no doubt that it is a great document. (more…)

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