We’ve been experimenting with one week sprints on two current projects. So far the results have been less then stellar. The teams themselves decided on the one week sprints. In one case they just argued strongly that they could add value within a week and then get rapid feedback from an internal customer. In the other there was only 3 weeks left to complete coding on a product, so it was broken into 3 week long sprints.

So far a few observations:

• It’s very difficult to get a regular rhythm in a single week.
• A few absences or company events can really take the wind out of a week long sprint. On a two person project one of the developers was out 3 of the 5 days of the Sprint. So we pushed quite a few user stories over into the next Sprint.
• The overhead is higher with more demonstrations and sprint planning meetings. There also isn’t a lot to show to the customer that’s new.
• One week sprints have a tendency to degrade into 1.5 or two week long sprints anyway. This happened on one project because as things slipped the sprint just got extended. This was really more of an issue with holding firm on time boxing, but it was related to attempting the one week sprints in the first place.
• You really need to break down user stories or features into small tasks, preferably mostly 2-4 hour level tasks. On the project where we didn’t really break things down we realized the team had taken on far too much.

The outcome of these experiments is that I’ll argue strongly with my tech leads if they want to try one week sprints again.

This is a little rendering by yours truly from a current Sprint. Your average 3 year old could probably duplicate this scribbling, or as my daughter refers to it as “scribble-scrabble”. I just hope to add a tiny bit of whimsy to the project.

An old issue came up today when a developer dropped by my office and asked whether he should be putting the jars for his project in the project’s lib directory or loaded into the shared JBoss lib directory.

My default response was no, but I’ve gone ahead and thought about it a bit. Based on my experience as a consultant and building projects on servers I didn’t control I never wanted to worry about the app server and what was out there so I always included all the jars I needed. On most frameworks or tools I’ve looked at they were pretty much setup the same way. Going further back from my Perl CGI days long ago it always drove me crazy that many Perl apps required a ton of dependent libraries that you always had to dig up on CPAN. So inherently I like the idea that I have every library I need stored with the project.

The developer made the argument that it was better to reuse the jars in the shared server library. And he was concerned about deploying large WAR files. The large WAR files is pretty much a non-issue, given the requirements most places have and the overkill hardware this never seems to be a problem. I also don’t like classloader issues when they crop up and encapsulating everything pretty much takes care of that. Still the reuse argument is pretty basic.

Of course this means if you have a dozen projects deployed and you decide to upgrade some version of a commons jar you may have to clean up 12 different projects even though many of them are probably never going to need to be touched otherwise. And in our environment some of our applications will deploy to JBoss and some to Websphere which seem to handle class loading issues differently. According to IBM wisdom apparently they suggest keeping all the libraries in the EAR or WAR. We’ve heard the same thing from some of their consultants.

So I think we’ll still encapsulate all the jars with the project, but I’ll probably run the idea by some of my senior developers. Never good to assume you know the best way of doing things.

After getting XPlanner running late last night on my iBook, I got a chance to try it on my PC at work late this afternoon. After dropping back to MySQL 4.1 instead of MySQL 5.0 the install went pretty cleanly and all of a sudden I could add users to a project and assign them to tasks. Of course when adding new users to get them to show up you still need to recycle your app server, Tomcat 5.5 in my case.

I spent some time going through the interface tonight. As per usual with an open source project there is fairly minimal documentation, but you can flail your way through the interface and figure it out. For Scrum one hint I did find is to setup a Product Backlog Iteration far in the future, and then move them into Sprints as they get lined up. The time tracking is more sophisticated then I need and I probably won’t use the tool to have the developers individually track their time. One funny think is that none of the charts appear. Apparently they fire off and run on some sort of overnight schedule. Considering mine’s on a laptop I’m not sure I’ll see the charts tomorrow.

Right now I think it’s going to meet my needs well enough for a basic tracking tool, and it saves me from Excel hell.

I got really excited that I was finally going to be able to install XPlanner on my XP laptop for work by pulling down the latest source with subversion, 0.7b2. Unfortunately the results have been eerily similar to the first attempt. Essentially I can never add a person to a project, making it well nigh useless to use.

So back to my trusty Mac OS X iBook. After about 90 minutes I got XPlanner 0.6.2 up and running and learned that MySQL has a very nice GUI installer for the Mac these days. The only major change I had to make was to change localhost to 127.0.0.1 in xplanner.properties:

It still feels a bit clunky, but I think it’s usable now that I can add people to tasks. Even though it’s late I feel a lot better getting over the frustrating hurdle.