• Implementing Scrum/XP Practices using Team Foundation Server, by Tommy Norman : how various practices, including CI, can be implemented using Microsoft tool
• Build and Test in the Cloud – CI and Cloud Provisioning for Agile Teams, by Darryl Bowler: demonstration of CI practices, with the twist of using cloud-based systems
• Java and Ruby Tools for Code Quality, by Steve Hayes: using Continuous Integration as a platform for code quality tools
• Top ten secret weapons for performance testing in an agile environment, by Alistair Jones and Patrick Kua: according to the session description, there will be a connection with CI; that could be really interesting
• Continuous Testing Evolved, by Ben Rady and Rod Coffin: CT will be presented as an extension to CI
• Killing the gatekeeper: introducing a continuous integration system, by Francis Lacoste: an experience report on applying a CI system
• Continuous Integration of the World, by Patrick Debois: integration of production environment using CI
• Agile Source Code Management using Stories, Agile Workflow, and CI, by Damon Poole: real-world techniques that allow change management of features, and synchronization with source code
• Executable requirements: BDD with easyb and JDave, by  John Smart and Lasse Koskela: not directly related to CI, but it will mention how to integration BDD with your build process
• WANTED: Seeking Single Agile Knowledge Development Tool-set, by Brad Appleton and Peter Alfvin: this talk will, among other things, talk about applying agile practices, including CI, to non-code knowledge development
• Patterns of Agile Adoption Practices, by Amr Elssamadisy: CI is one of a set of practices that attendants will be asked to prioritize for discussion
• Large scale continuous integration, by Hannu Kokko: real life experience, with hundred of developers
• Automated deployment with Maven and friends – going the whole nine yards, by John Smart: how to automate deployment using Bamboo, JIRA and Nexus in a real-world multi-module Maven web application
• Build Engineer Bootcamp: Builds As Code, by Paul Julius & Jeffrey Fredrick: will discuss build systems, a topic very close to CI
• Removing Integration Delays with Collocated Whole Teams and Multi-stage CI, by Damon Poole: why and to implement multi-stage continuous integration in large distributed environments
• How to run 4.5 Million tests per day … and why!, by Mark Striebeck: how Google implemented a huge CI system for its own needs
• Enabling Agile Testing through Continuous Integration, by Sean Stolberg: how a CI system enables agile testing practices
• Continuous Integration: Your New Best Friend, by Howard Deiner: what CI is, and how is fits with unit tests, acceptance tests and development habits
• The 7 Deadly Sins of Almost Being Agile, by Bob Hartman and Richard Lawrence: never integrating is one of the sins discussed
• Creating Habitable Code: Lessons in Longevity from CruiseControl, by Jeffrey Fredrick and Paul Julius: not strictly about CI, but the tool discussed is the one that made CI popular, so this will be of interest to build experts
• Experiences Applying Agile Practices to Large Systems Development, by Harry Koehnemann: CI is one of the practices discussed
• Herding Cats: Managing Large Test Suites, by David Kessler and Tim Andersen: strategies to maintain automated test investments
• CI vendor cage-fight!, by Tom Sulston and vendors: 10 mins demos of all CI tools with representatives in the conference
• From Cowboys to Agilists – Organizational Change at Overstock.com, by Sean Landis and Kevin Steffensen: CI is described as one of the practices deployed to solve the software development crisis at overstock.com
• The Ogre and The Wimp: Clever Influencing Tricks – Help the Most Reluctant Teams, by Anda Abramovici: among other things, how to get the “I only run the build once a month” dev to do it every couple of hours, and how to get the “I only check in code once I’m completely done” dev to practice frequent check-ins
• Agile Infrastructure, by Andrew Shafer and Paul Nasrat: continuous deployment will be especially discussed
• Applying Agile Development Practices to Atypical Technologies, by Scott Dillman: CI is described as part of a case study
• How to be really awesome at Continuous Integration, by Tom Sulston and a panel of luminaries: discussion of the audience’s problems and questions
• Java Power Tools – getting it all together, by John Smart: use to how Hudson and other tools for a software development infrastructure

Phew! That’s quite a mouthful. Interestingly, there are many more talks listed here than I managed to get last year (and there are half as many talks this year). One reason could be that I was much more thourough this year, reviewing most of the sessions details — last year, I simply searched for keywords in the submission system.

To be honest, seeing as many sessions related to CI is rather a disappointment. I mean, CI is not a difficult practice, and you would think that many participants to Agile 2009 would be familiar with me. Plus, most sessions are introductions rather than advanced talks.

I guess I will content myself with Tom Sulston’s sessions (”Cage Fight” & “How to be awesome”).

• Java Power Tools – getting it all together by John Smart, 
• Build and Test in the Cloud – CI and Cloud Provisioning for Agile Teams, by Darryl Bowler, 
• Agile Tool Hacking – Taking Your Agile Development Tools To The Next Level, by Craig Smith and Paul King,
• CI vendor cage-fight! by Tom Sulston: in this one, various tools vendors, will demonstrate their CI server — I might do the Hudson one

OK, I do prefer Hudson (I am a contributor, after all). But I also watch the competition… err, I mean, like the other tools ;-) Here are other presentations I could find that mention competitors to Hudson:

• (CruiseControl) Agile Source Code Management using Stories, Agile Workflow, and CI,by Damon Poole
• (CruiseControl) Creating Habitable Code: Lessons in Longevity from CruiseControl, by Jeffrey Fredrick and Paul Julius
• (CruiseControl) Build Engineer Bootcamp: Builds As Code, by Jeffrey Fredrick and Paul Julius: though not explicitly about CruiseControl, the hosts are the main contributors to CruiseControl, so expect to hear about it!
• (CruiseControl) Continuous Integration: Your New Best Friend, by Howard Deiner
• (Bamboo) Automated deployment with Maven and friends – going the whole nine yards, by John Smart: though it does mention Hudson, the focus will be on Bamboo
• (Bamboo) Large scale continuous integration, by Hannu Kokko: the session outlines does not explicitly says so, but it seems that Bamboo is part of the toolset

Things have been moving for our little group.

Agile France

First and foremost, the group is renaming itself. It will thereafter be known as Agile France.

The extended French-speaking sphere

Second, its bylaws changed to reflect that the group is willing to help anyone in the extended French-speaking sphere (ie. French-speaking countries, non-French groups in countries where French is spoken, and French-speaking groups in countries where French is not an official language).

6-member strong board

Thirdly, a stronger team of people has been elected members of the board. We are jumping from 3 (Laurent Bossavit, Gabriel Le Van, Patrice Petit) to 6 (Raphaël Pierquin, Bernard Notarianni, Sandrine Olivencia, Antoine Contal, Laurent Bossavit). This boardis elected for 2 years.

What to think of all this?

• in my view, the name change is excellent. I do believe that it will give more credibility to the organization. I remember talking to someone who thinks that the French Scrum User Group had been created in part because they felt that Scrum was not well represented by XP France — he repeated that this was clear to him, considering the name. I do not believe XP France is neglecting Scrum, but it is just as well that the name makes it clear.
• specifiying that the association is willing to help the whole “extended French-speaking sphere” proved to be controversial. I personnally do not care much, but many thought that we can get into conflicts with other groups, such as Agile Québec. I’d personnally be very surprised if that becomes a problem.
• though I agree that the new team looks strong and motivated, I am disappointed by the slightly heavy handed manner. We were basically told “oh, we are also going to change the board and, by the way, there is the only team you can get to vote for”. A simple email to the mailing list would have helped make things easier. I think. Also, a few people seemed to be disappointed, as they would have been candidates, given the chance.
• I am also disappointed by the rather long mandate (2 years, down from 3 years in the original proposal). One argument was that 1 year is not enough to let the board members settle, and they would then be judged unfairly for their first year. Well, who’s saying that the members of the association would be so harsh as to kick them out if they can explain why they haven’t achieved much? Surely, a reasonable explanation is not too much to ask.

Anyway, at least it seems that the association is doing its best to be as relevant as possible. I think those changes are for the better.

See you next year and all the best to the new board! There is certainly work to do  for everyone.

• Check out my pictures from the meeting

I thought I would give more details here.

Our goals

We didn’t exactly manipulate the participants, but we certainly did not reveal, on purpose, what our goals were:

• help dissenting voices come out of the closet — very few people are vocally criticizing Scrum today in France, and I have found no blogs. I wanted to show the pro-Scrum side that they do not have the final word.
• let people vent — both pros and antis
• make participants think — one later came to me and suggested that I should have offered “alternative solutions”. Well, I have none (though I do have some starting points, see below)

Alternative endings

We had prepare additional materials, in case the discussion died out. Fortunately, it was so lively that we couldnt use them at all. You’ll find all three of them below.

You are not alone

The first thing I wanted to highlight is that, though dissenting voices on Scrum (or Agile) are not currently heard in France, they do exist in the rest of the world:

• James Shore has blogged that “when people say “Agile,” they usually mean Scrum” and that “it’s very easy for teams using Scrum to throw out design“. Finally, he points out that the “Scrum makes it worse by ignoring important (but hard) agile engineering practices, and the Scrum Alliance makes it worse still with their armies of trainers [...] issuing dubious “ScrumMaster” certificates to people“. There is more in today’s article on InfoQ.
• David Anderson lobbyied hard for an ‘Agile Fringe’ stage at Agile 2009 Conference, feeling that the vocal agile community is too mainstream. I agree with him, and I feel that the Agile 2009 program could have given more room to dissenting voices. The Agile Frontier stage is not bad, but it should have gone further.
• Naresh Jain says that Agile (as practices today) is the new waterfall.
• which reminds us directly of Steve Freeman’s aphorism, uttered during CITCON Amsterdam: “Scrum is the new RUP”
• some people did manage to get controversial sessions accepted to Agile 2009. Not all are directly related to Scrum:
  • JB Rainsberger: Integration Tests are a scam
  • Bas Vodde & Steven Mak: Let’s Stop Calling It Agile
  • Paul Hodgetts: ScrumMasters considered harmful – Where did it go wrong?
  • Brian Foote & Joseph Yoder: Big Balls of Mud: Is this the best Agile can do?
  • also, there might be good content at Linda Rising’s Agile: placebo or real solution?
• last but not least, Alistair Cockburn, author of the Crystal family of methodologies, signatory of the Agile Manifesto and Certified ScrumMaster Trainer, will host a keynote at Agile 2009 entitled “I Come to Bury Agile, Not to Praise It”

Scrum has Crossed The Chasm

There is a model that give hints to the current situation with Scrum. It is the Technology Adoption Life-Cycle, as amended by Geoffrey Moore in his seminal book “Crossing The Chasm“.

In short, it appears that many of the arguments against Scrum do not just mean that it is poorly explained, nor just that it is poorly understood, but rather that it is now being adopted by a large number of people. Or, to rephrase this, that it has been (consciously or not) packaged in order to be palatable to the mainstream. This implies trainings, books, consulting services, explanations, case studies, success stories. In short, packaging the approach just like a marketing team would do. That the people behind Scrum did it on purpose (as I believe) is beyond the point: the Agile approach that wins the hearts and minds of IT professionals everywhere is necessarily the one that comes with such as package, a whole product, in the words of Moore.

That is a reality that people that are blindly against Scrum must acknowledge.

ARXTA

Finally, I would like to point any aspiring Scrum-evil-ist to Brian Marick’s writing on Agile roots. His argument is that “Agile” (and, I guess, the names of pretty much all Agile methodologies) is too easy a term to adopt. In other words, many people will look at the name, glance at the practices, and quickly come to the conclusion that “hey, this is exactly what we’ve been doing all along! Let’s avoid asking ourselves hard questions and let’s not change the way we work.” Which is, obviously, missing the whole point.

Brian has came up with a new name for the roots of Agile: “Artisanal Retro-Futurism, crossed with Team-Scale Anarcho-Syndicalism.” The name is cryptic (and even slightly repulsing) on purpose, so that people will have to ask, and will have to have a conversation.

Further reading

Check out

• my photos of the notes taken on easel pads
• the transcript (in French) of the session by Nicolas Martignole (Google translation in English); he even has a recording somewhere on his site
• my notes from the session at CITCON Amsterdam 2008
• “Is Scrum Evil?” a question asked by Jeffrey on Stackoverflow

• Staffan Nöteberg is back with The Pomodoro Technique: can you focus – really focus – for 25 minutes? this is the presentation I saw in 2008 that I liked so much (the pictures on the header on Staffan’s website are those I took then) An excellent (and entertaining) introduction to the Pomodoro Technique, I heartily recommend it.
• You say tomato, I say Pomodoro is another introduction to the technique, this time by Renzo Borgatti
• There will be a quick mention of Pomodoro in
  Ineffective Pairing, How To, a session that was a big success last year (I had fun rehearsing the pairing situations with Ryan Hoegg in the halls)
• finally, Staffan already told me he’s planning to arrange some kind of informal daily workshops where people will practice Pomodoro. I’m looking forward to that, as I have so far lacked the discipline to practice it regularly.

Coming up is XP Day Paris, May 25th & 26th (next week!). No less than 3 sessions will be presented by yours truly:

• Introduction to Retrospectives, with Laurent Bossavit
• TDD Explained to Managers, with Stephane Labati, a former colleague from Valtech
• Is Scrum Evil? a workshop with Guillaume Tardif — the session I’m most excited about!

I will be at the dinner on Monday evening as well; feel free to come and talk.

In August, I will be at Agile 2009 Conference in Chicago. This time, I will host a Coding Dojo on Legacy Code, with my partner in crime Guillaume.

Unfortunately, Is Scrum Evil?, a session I had proposed with Jeffrey Fredrick, has not been accepted. Fear not! We will be back with a revenge during the Open Jam part of the conference. I have hope many big names of the Agile world will join us. Promising session, trust me.

Next, September 18th will see CITCON Paris. This conference is dear to me — I have participated to all previous European CITCON events, and I am sure this will be one to remember. 3 months to go and the list of registrants is already closed!

As you may know, this is an Open Space event, so sessions are not known in advance and will be discovered during the opening session. Sounds scary? Wait until you suggest a session! ;-)

Other events of note this year will surely be Valtech Days 2009 and Devoxx. I have helped organize Valtech Days in 2007 and 2008; having left the company, it will not be the case this year, but, who knowns? I might still get to host a session.

As for Devoxx, I have never participated so far, but I heard so many good things that I really want to make the trip this year. We’ll see.

Well, this will be a busy year. Hopefully, I will have a few vacation days for non-techie stuff as well!

My colleague David recently wrote a controversial post on Maven and what is wrong with it. As his neighbour in a cramped office room, I feel compelled to give my own opinion about it. Which fits in a few words: it ain’t too bad.

Maven did get some things right

My argument is that Maven did help teams to Get Work Done, mostly by paying less attention to the build system. I enjoy playing around with build scripts and the like, so I’d rather dabble more with them, as I used to in the heydays of Ant. But I can’t justify it anymore. Maven has allowed me to concentrate on more value-adding work.

But, obviously, that does not make it an all-around Good Thing. It does have its flaws. Yes, the dependency system is not great (I believe this can be partly alleviated with proper unit testing). Yes, too many people use it in too many situations. In a word, the paradigms in Maven break when pushed too far.

Well, couldn’t the same be said about Ant, Java, Microsoft Windows, or even computers?

Leaky Abstractions

All these things are Leaky Abstractions. They try to make our life easier by hiding the complexity, while in truth there will always be a point where the abstraction breaks down. This happens pretty much any idea is made concrete by some implementation. There is an inevitable point or situation where is does not work anymore. That is part of life, and no other build system will ever perfectly.

So they ARE lying then!

Of course they are. Nobody ever sold anything by saying “well, our tool is reasonably good, but keep in mind that it does not work in many situations” (and even open-source projects need to sell themselves). No, they must always oversell a bit, if they want a fighting chance (check out the website of any software if you do not believe me). If that means that some users will later be disappointed, that’s a chance they are ready to take.

So, what can we do?

If you are so inclined, feel free to provide your own solution, as long as you make it available to the world. But be aware that, despite all its benefits, at some point someone will come and bash your little tool, for the right reasons.

Or, you can periodically survey the available tools and change every time one seems better. Or wait for an external consultant to come to your project, laugh at you and point you to this new thing that “everybody is using.” But, in the end, if you want to keep your sanity, always take claims with a large pinch of salt.

I find that these events are often more social than technical. There are a means for many to catch up with colleagues and friends. As for me, I was delighted to chat with Jean-Laurent, Grégory Paul, and many others, as well as meeting Nicolas Martignole for the first time (indeed I almost missed out on the excellent buffet).

Still, one thing I was really interested in, is Rich Internet Applications (RIA) Frameworks. I don’t know about you, but me, I have been hoping for a while that a clear leader would emerge. Probably because I have been spoiled by such an experience in the past (remember the good old days of Struts 1?). So I naturally suggested a session on RIA Frameworks which got a pretty large turn out.

Executive summary: there is no clear leader. However, Flex, GWT, jQuery emerge as the oligarchy dominating the area (.NET frameworks were not discussed, given the Java-leaning crowd).

Details

My original question was “What is the best RIA framework for professional development?” I didn’t want to discuss flashy new tools, only those that dominated the marketplace and that a company could capitalize on.

The frameworks mentioned by the participants were (in bold, those that are used the most by the people present in the session):

• GWT: an obvious option for Java programmers, since it appears almost anything can be done in Java. Generating production-level pages can be slow. Many libraries available for it, either as native-Java libraries, or as wrappers for Javadoc libraries (to be avoided if possible, as they are harder to control and to use TDD-style)
• jQuery: a library now frequently found on high-traffic sites, which has been officially approved by Microsoft
• Flex: the only one to provide a complete solution. Someone was using it as the only solution for frequently displaying financial data.
• scriptaculous
• Yahoo! UI: good cross-browser support, but quite complex to use
• Java FX: a person viewed it as an interesting option for mobile devices, but few are betting on it. Apparently, it does not require a browser plugin (apart from a recent version of Java)
• Other tools mentioned: Google Visualization API and its GWT-GVis simplification layer (for generating charts), Prototype (Ajax & GUI JS library), qooxdoo (Ajax & GUI JS library), LightView / LightBox JS (both for specific image display, based apparently on Prototype), Dojo (Ajax & GUI JS library), phoneME (a technical library for Java on mobile platforms), Ext JS (yet another popular Ajax & GUI JS library with a GWT wrapper; proprietary. Apparently, the models are a bit complex). Even Silverlight was mentioned.

From all this transpire that there is no clear leader in the RIA space. The one that is the most likely to be around the longest is probably Flex. But, as mentioned, it is not an answer to all issues. Though well integrated with Java development, it is not as natural to use as, say, GWT. In fact, GWT seems to be the only real Java-friendly solution, an important argument given the hordes of Java developers with few Javascript skills. The issue, of course, is that GWT is not a complete solution: its graphics capabilities are more limited than the competing JS libraries. Its Ajax features are not the best either, especially if you design a very responsive application, such as a financial app.

So, here is my opinion:

• personally, if you want to branch out from Java, then Flex sounds like an interesting way of doing things that look good
• as a company, if you want, to bet on a new technology and can afford to train your staff, Flex is here to stay so is probably a safe bet
• as a company, if you want to leverage your Java developers fast, then GWT is probably the way to go; in that case, you will also have to use additional Javascript libraries, starting with JQuery

That reminds me of the time I was trying to tell my acquaintances about blogging or even (a long time ago) about this new thing called “the internet”. No, Twitter is not that useful. It is not going to save world hunger or give you a new job. But still, you should give it a shot. Here is my attempt to organize my thoughts a bit.

In theory, on Twitter, you are supposed to tell about what you are doing right now. For many, it means telling the world about the coffee they are drinking and other trivial things. This is not how I use it.

There are 2 types of people that I follow:

• friends and colleagues: Twitter offers me a way to keep in touch with them even though I don’t meet them in person frequently or even call them. From these people, I enjoy both work-related tweets (”I got XYZ to work, it rocks!”) and mundane ones (”My little one is just one year old!”). Twitter is a low-friction way of talking with them, what Jeffrey Fredrick calls a replacement for a beer. Often, I miss what they say when I was not connected but that does not matter. Twitter is not a chat system. Sometimes, I respond to this type of people, or even DM them (ie. send a direct message). Anyway, as long as I get news occasionnally, I’m happy.
• thought leaders and people I want to hear more: many figures in the domains I’m interested in now have Twitter accounts. Often, I already read their blogs, but that is not enough. Blogs are infrequent matters (less and less frequent as they embrace Twitter), and only well-formed thoughts appear on them. This is all good, but Twitter is where they talk about their day-to-day work. Sometimes, they would post half-formed thoughts (”what would happen if we stopped doing X and started doing Y instead?”). Sometimes, they would tell short things that do not deserve a full-fledged blog post (”Theory X is probably the most interesting thing I heard about this year”) or give links to page (”Check out this article — I recommend it”). Very occasionally, I would respond, or, more commonly, RT (re-tweet) their post so that my own followers are aware of things I find interesting. Like the others, the people I consider thought leaders also tell about their life. That is not so interesting, but unfortunately it is not easy to filter them out. That’s is the biggest drawback.
• competitors: in a way similar to the friends and colleagues, I am interested to learn what they are working on. Obviously, I can only learn about what they are willing to tell. Still, it can be interesting. And over time some of them tend to the “friends & colleagues” category.

Over the months, I have built relationships with some people, learned the opinions of thought leaders on Fit, ask for help in selecting a mobile phone, followed Uncle Bob’s progress on Fitnesse/Slim, publicize various events that I was involved in… and arrange for a Twitter board to be displayed during a conference.

All these things can, in theory, be done via blogs or social networks sites. But the low friction of Twitter makes it so much more easy to use.

My advice is: get your own Twitter account and follow people you know. If you have things to tell that are not roo mundane, by all means, tell them. And do regularly clean up by stopping to follow posters that have a high signal/noise ratio.

Feel free to follow me, if I meet your own criteria for Twitter.

However, it can only go so far to prevent your code base from swelling permanently. In theory, if your revenues keep growing, you can keep recruiting more people in your development team, and all will be good. Unforunately, that’s not usually how software works.

Like many other things in life, software goes through well-known phases: birth, growth, maturity, and decay. At some point, the costs of maintaining the software are just not justified anymore and the editor pulls the plug.

However, we can do a little better than that. If the project still has some life in it, it can be a better plan to reduce its complexity, in order to lower its maintainance costs and increase its life. In fact, there is no need to wait for the product to decrease in popularity. Housekeeping should be done as early as possible in the lifecycle. No need to maintain features that cost more than they pay.

My current customer has exactly this problem. Their project suffers from feature creep. Regression tests become more and more costly to maintain (it is actually planned to delete some of them regularly — though, of course, nobody really knows which ones we can afford to throw away).

I would call the activity I’m promoting “Feature Refactoring: the process of changing a computer program’s list of features (and corresponding code) without modifying revenues significantly” (balancing short- and long- term revenues). This means that it is OK to remove some features, as long as it is acceptable to your customer base, in terms of money to make in the long term. Basically, you want to avoid the classic pattern where 80% features that are little used or not used at all.

Note that I am not merely talking about features representing significant weight in terms of code, tests, or documentation. Rather, I want to target anything that costs money to maintain, understand (for new hires), market, etc.

How can we do this? Well, here are a few smells that can help

• your client representative tell you about it — the easy scenario
• you detect that few customers actually use your modules – monitoring tools can help you here
• you find bugs in production… and few people actually complain about it — should this feature be there at all?
• you upgrade your project… and nobody complains — if your features are popular, someone is bound to complain about any change
• specs for a particular feature are not updated — features that do not evolve tend to rot
• run workshops with customers — a interesting format for this is Speed Boat

My point is that there are even more potential benefits in term of code maintenance when removing features, compared to refactoring the code base (which is a good thing to do, too).

Refactor your features. See this one there in the corner? You Aren’t Going to Need It.

You’ll be happier.  And you will probably save money.