As a project manager on dozens of projects I have sent hundreds or perhaps thousands of project status reports. I’ve read even more status reports as a development manager often showing up Friday afternoons in the old inbox.

Every status report needs to cover the basics like budget, scope, and schedule. Other than that the big thing is to point out new risks or items that have been mitigated. In an Agile context the status reports can often be eliminated entirely, but it tends to be a document people hold onto when getting adjusted to Agile. They often looks like paper versions of dashboards with the traditional red/yellow/green designations. All green means no need to read. Then again I once worked for a director who was actually color blind so I’d make sure the colors are also spelled out.

As a PM I remember borrowing my first status template from another PM who had in turn adopted it from her time at Andersen Consulting (Accenture after the rebranding). I adjusted it, but I’ve used it ever since. I can’t say I have a favorite format for project status reports, but I do know they need to communicate the key points as succinctly as possible. As a PM it’s important to know who’s going to actually read these reports. Some of your audience much prefers to here a verbal update even if it’s very short.

As a manager the best approach to status reports is to stay directly connected with your projects so you don’t need to rely on them. You should be spending a significant portion of time with the bigger projects or the projects that are struggling potentially only relying on status reports for the well oiled smaller projects that are just getting done. And don’t forget to reward those projects that are just getting done right without much need of your services. These are the well managed projects that should be rewarded more often.

Finally, I think I should expand on email and status reports. As managers you typically get 150-200+ emails a day many CCed or forwarded to you as an FYI. When you send that very detailed status report as a Word attachment much of your audience will never read it. I realize PMs often spend a painful 30-60 minutes tweaking the status report to send out every week only for it to go almost completely unread. What I really want is the key points of the status report directly in the email. That means you can send the attachment, but make sure you copy the critical stuff into the body of the email. The pain involved in not being able to read it in the preview pane, having to click on the attachment, wait a few seconds for Word to bring it up and render it just to start reading that nothing critical really happened this week often isn’t worth it. And an email link to the status report buried in project server is rarely any better. So, please don’t rely on attachments.

A few weeks ago at the local Ruby Users Group meeting there was a suggestion of actually writing some code at the meeting. The suggestion was to use a Ruby Quiz exercise. It was quiz #16, a Rock, Paper, Scissors simulation. We broke up into small groups of about three people, coded for maybe 45 minutes and turned in our solutions. My team came in last but it finally pushed me to actually take up a long neglected todo item to start doing coding katas on a regular basis.

I’ve done the classic Bob Martin TDD bowling kata for years as an intro to TDD. I’d also walked through a one day tutorial from a Dave Astels session on Rspec back in 2006 that was very much a game based kata. I’d read about Prag Dave’s coding kata ideas, but I’d never quite found the time to start the practice.

Last week I started utilizing two major resources:

• Prag Dave’s original CodeKata site.
• The KatCatalog from the Coding Dojo wiki.

I’m jumping back and forth between Java and Ruby in the katas to stretch my skills. I may even add in Groovy at some point, but Groovy and Ruby styles are pretty similar. I’m trying to take on one per day and when I wrap around I’ll try out different languages. As a committed TDD student I’ve started each kata with a test. I have to admit RSpec makes this a lot easier when using Ruby and autotest is a wonderful tool. At least I have annotations and JUnit 4+ when I’m doing the katas in Java. For IDE’s I’m bouncing between IntelliJ for Java and TextMate for Ruby. I’m even taking the opportunity to test out git and I setup a github account to store the katas so I can see how I evolve over time.

If you haven’t tried out the practice I might suggest giving it a go. One of the best things is I get to really focus on coding for about an hour a day and it blocks out the rest of the world. Mostly I’m doing them in the early morning to cut down on the interruptions. I’ll probably post again on my observations after a month or so.

I realized today that I’m #152 on a list of the top blogs for developers. Jurgen Appelo (NOOP.NL) has been compiling lists like these for a bit now and this humble little effort manages to do pretty well. Jurgen himself has made a great effort to put out quality content on a regular basis with a management perspective. As there’s not a lot of software development managers posting these days it gives you some rare perspective if you’re a developer working for one of us pointy haired bosses.

I’m now part of 11.5% of all California workers looking for work. My organization decided strategically that they didn’t want to do in-house development, hence they didn’t need a development manager. I just wish I had gotten a longer chance to show the significant quality and cost benefits of maintaining a development team in-house.

There is shock as you realize your routine has changed. It settles down after a few days. Next came the silver lining that comes with this sort of change:

• Doing coding katas every morning to tighten up my programming chops. I’m alternating between doing solutions in Ruby, Java, and Groovy.
• Looking at options to do something I’ve been passionate about like Agile coaching, QA management, or old fashioned professional services.
• Attending some conferences and user groups in the Bay area since I have some travel time.
• Reviewing some open source projects I always wanted to contribute to.
• Catching up with friends in Sacramento over lunch.
• Hanging out with my two daughters including picking them up on bikes last week.

Sacramento isn’t the biggest tech market and it’s home to the state of California government and their massive budget issues, but I’m confident I’ll find a good opportunity.

I’ve heard about git and decentralized version control systems like Mercurial for a few years. Conceptually it sounded interesting, but not compelling. Over the years I’ve used the following version control systems:

• No version control – a very early web startup around 1994. I was blissfully unaware of version control at this point.
• VSS – A horrible experiment in using a Windows share as version control. Better than nothing, but just barely. I’m glad to see Microsoft finally retired this beast with the Team System source control. From the few stories I’ve heard Microsoft never really used VSS themselves and I believe they used to be primarily a Perforce shop.
• CVS – My first love among source control. For months at a startup in Vegas we had to use VSS on servers that were located at the main office in San Francisco. Just listing a directory could take minutes. After a few months of political battles we finally won them over after the CTO learned one of our developers had to fly to SF with a CD because it was the only way to get a medium sized java project checked in. It was great because it just worked. And the speed was wonderful even if it’s a bit slow by today’s source control standards.
• Harvest – They asked us to use this at one client site. They sent out a special trainer to show us how cool it was. The visual client actually used a combine reaping wheat as the animation when you checked in. It took us just a few hours to drop it and just install a local CVS repository and show the rest of the team had to use it. Computer Associates owns the product now which is a sure sign it’s at the very end of it’s life.
• Perforce – Most recently I joined a shop that used Perforce. I had never heard anything bad about it other than it was a commercial solution which meant some limitations on support in various tools. I found it a bit difficult to adjust to the terminology such as ‘client spec’ and other items, but I was pretty happy with it’s speed. It was noticeably faster than CVS. Of course it also caused headaches because it’s integration with various open source tools wasn’t the best. One particular pain point was the Hudson plugin. It turned out some bad decisions had been made in the central repository with relation to directories that contained spaces, despite being hosted on Solaris. Without quoting all the paths the checkouts just failed and the Hudson plugin wasn’t setup to support this.

Early on at the last organization I was leading towards migrating quickly to Subversion. Eventually given the number of contract developers I would impact I put the decision off until some later time. Subversion has great support these days as the CVS replacement, but I knew git and other options were out there. Perforce also didn’t have any critical issues and was easy enough to manage since we had already purchased a number of licenses.

My developers really wanted to ditch Perforce for Subversion. As a developer at heart I completely agreed with them, but given all the challenges on our plate the argument just wasn’t compelling enough from an organizational standpoint. I had a similar recent conversation with our EA manager who asked if we were looking at moving to Glassfish soon over JBoss since we were on a non-Redhat supported version. I pointed out that we had piloted Glassfish recently and were happy with it, but I wanted to wait at least a year to see what the Sun Oracle merger will mean for the Glassfish developers. No one wants to migrate away from JBoss to experience something like what happened with Geronimo.

All the while git in the background git was picking up a lot of traction. I finally broke down recently and purchased Pragmatic Version Control Using Git. Even if it doesn’t end up being the right choice for today and I settle on Subversion for now it would appear the world is headed in that direction in the near future.