Today I stopped bothering to update XPlanner. Part of the Agile method is to “do the simplest thing that works.” XPlanner wasn’t really a simple install, but once I adjusted to the user interface it made at least logical sense. The problem is:

• I already track my Scrum projects on white boards with sticky notes.
• I already use 3×5 cards for user stories and tasks.
• I do the time tracking, because time tracking really demotivates developers.
• My developers are all collocated so they can see the white boards at the daily standups.
• Tracking time takes way too many clicks. (I can see why they’re considering a nice friendly Ruby on Rails version with AJAX support)
• The graphs only update once a day and really didn’t work that well for me.
• Excel isn’t so bad.
• It was just slowing me down and duplicating work I was already doing.

So I’ll toss a note to myself to check in on it maybe a year from now or look at a commercial option like Rally if I feel the need again, but for now I’m back to 3×5 cards, white boards and Excel.

Apparently my assumption that there will eventually be a podcast for every niche is starting to happen. Cocoa Radio is an entertaining podcast devoted to independent Mac software developers developing in Cocoa. So far there’s only a few out there, but the focus is on interviews with independent Mac developers like Brent Simmons of NetNewsWire fame. Not sure it’s enough to inspire me to pick up a book on Objective C, but heh, you never know.

I regularly ‘google’ potential hires to see if I can find out any useful information before even getting to a technical screening phone interview. Sometimes you can’t find much of anything on a candidate even a candidate with an unusual name. I don’t read a lot into this but I often wonder about it. If you’ve never posted a comment on something like TSS or some other searchable forum, don’t have an old blog, or a bug report on sourceforge are you just trying to hide something? Since I’m almost always hiring for web development seeing a candidate’s content out there on the internet is a big plus.

I love coming across candidates who have web sites or who have made a lot of posts to newsgroups. You can really get a good idea about someone from even how they ask for help with some configuration issue. Unfortunately I think a lot of technical people realize anything they put out on the public internet could possibly be used against them later, so they generally avoid it. I think the advantages outweigh the risks, but that’s pretty obvious.

The one time this did impact me in an interview process I got attacked for posting something on a Mac forum I had forgotten about. After three interviews I was on yet another interview with the head of networking for a company. He apparently was a Microsoft bigot and believed that the world should be Windows NT. The company already was starting to annoy me because they couldn’t make a decision after three separate interviews. This was in 1999 at pretty much the height of the dotcom bubble so I have no idea how they thought someone wouldn’t find a better job in the month long interview process they engaged in.

Anyway this the interview devolved into some weird attack interview which took me quite by surprise. I really didn’t see why it mattered that I used Macs as well as Unix and Windows machines. Anyway that was the final straw that convinced me not to even consider their offer. And I sent an email to the actual hiring manager explaining that being personally attacked because I dared to use Macs in an interview by a network admin wasn’t my idea of a good work environment. He replied back about a month later after he had left the company and apologized for the process. But by then I had found a great dotcom to work for. OK, it was a great experience. The company is of course out of business.

Anyway you can still find old Usenet posts of mine out there on rec.sport.paintball when I spent a lot of my freetime playing amateur paintball.

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.