I stumbled across a post by Mike Clark on rcov and how easy it was to get code coverage metrics. I’d installed rcov 0.6 like a year ago and it took forever to run and had other issues so I dropped any idea of seriously using it. Now trying 0.7 it appears to run perfectly well. So if you’re like me and really like coverage tools like Clover in the Java/.NET land rcov 0.7 appears to be a keeper.

Software Engineering Radio is a fairly heady podcast on computing topics. I’ve left it on my list for a long time even if I end up skipping through the occasional episode that delves into too many details on Remoting or Model Driven Development. Lately though I’ve really enjoyed their turn towards more interviews with people like Guy Steele working on a Fortran replacement or Werner Vogels of Amazon talking about massive scaling approaches. Might give it a try if you have some available listening time.

Turns out the first developer in our organization to actually bring in Rails and use it for something real is a Unix sysadmin. He needed to transform a spreadsheet of inventory into a little web based system and he had heard some stuff about Ruby on Rails and wanted to try it out. 8 hours later he had popped out his first app to replace a spreadsheet. And this is coming cold from no background in Ruby. He’s pretty jazzed about how nice and productive it is for web applications.

Setting up one-on-ones today:

• 10 employees.
• 1 30 minute one-on-one per employee per week.
• 6 months of meetings scheduled through the end of June.

Turns out this is 260 meetings over the next six months. The raw number of meetings would be enough to send the average developer running to Monster. Luckily the one-on-ones are really a handy tool to make sure at a minimum everyone gets at least 30 uninterrupted minutes with their manager to communicate concerns up, get help, vent, and get coaching or mentoring.

Goals in a typical Sprint:

• One Sprint goal provides a focus.
• Each backlog item is another smaller goal.
• Each day a developer commits to a small task based goal for that day.

Plenty of goals. Unfortunately we’ve also adopted an idea of interim goals on our 30 day Sprints. The idea started out as a device to help teams new to Scrum make sure they didn’t set off on cruise control and then scramble at the end of the Sprint. The idea was with an interim goal the team would make sure to jump in and work hard right away.

I think the whole interim goal was an OK experiment, but I also think it might work just as well to do 2 week iterations. The point was to use them while teams got up to speed. After everyone is used to working within a Sprint they don’t serve much of a purpose.

Today on a project after we made the interim goal it was suggested that we have an interim interim goal between now and the end of the Sprint. Two of the developers bluntly said no and eventually the whole team shot the idea down. Their snappy comeback involved just asking how that was going to add value. This is always a good question.

The whole point of a self-managing, collocated team meeting in a standup to sync at least once a day is that if some coordination needs to happen it can take place ad-hoc. Creating a goal around it and taping it to the wall doesn’t add any value.