I’ve used just about every defect tracking system there is. That includes Trac, Fogbugz, Lighthouse, a Rails-based Trac clone that I forget the name of, spreadsheets, note cards, and even Bugzilla. I haven’t tried Mingle, and I only used Jira for a few days, but I’ve got most of the other bases covered. Last year at Tumblon, we settled on Fogbugz as less painful than the other options. It’s a pretty good defect tracking system, with most of the right features, and it’s reasonably easy to use.

A month ago, I tried Pivotal Tracker for a new project. It blew everything else away.

I think there are two reasons for this.

First, it’s a story tracker, not a defect tracker. And when I’m building software, I need to track stories more than defects. Of course, Pivotal Tracker handles both, and so do most bug trackers. But bug trackers usually seem natural when I’m using them to track bugs, and unnatural when I’m trying to map out new development. Pivotal Tracker feels natural for both.

Second, it prevents sabotage. This is the real key. Software development projects are hard to get right. It’s really easy to unintentionally sabotage a software development project, and everyone on the team can do it. That’s why there’s a huge publishing and training industry around project management, and why most of us are interested in the software development process. (Things like Agile, XP, and Scrum) are probably interesting to you and I, while CMM and CMMI are interesting to other people.)

Basically, Pivotal Tracker enforces a lightweight agile process, and makes this painless. If you use Tracker properly, you’ll write relatively atomic stories, estimate their difficulty, prioritize them, step each one through a simple workflow from new to accept/reject, track weekly or bi-weekly iterations, and see where you’ve come from and where you’re going. You can do this with most bug trackers, but most of them are missing one important thing.

Constrained velocity.

Pivotal Tracker requires that every feature get an estimate on a simple scale – 0-3 is the default. These are relative velocity points, not hours, and they give you an idea of how much you can accomplish in an iteration. After your first iteration, Tracker uses the average velocity of the previous few weeks as the predictor of your velocity for the current iteration. So if you did 17, 15, and 20 points over the last three weeks, Tracker thinks you can do 17 points next week. Chances are, this is a decent guess.

The Current Iteration and the Backlog are a continuous list in Tracker, and the line between them is based on velocity. If you only have 12 points of work on an iteration, you can’t add stories to the next iteration – you still have capacity on the current iteration, so the stories will show up there. If you have 17 points scheduled for this week, and you try to add 2 more, something has to give. And this is the key.

By managing velocity in this way:

• The product owner can’t shove an extra 5 points of work on an iteration just because he wants it to get done, at least not without recognizing that it will take more resources (i.e. more programmers).

• The product owner can’t make every new feature the top priority just because it is new, at least without clearly seeing that other features will be delayed.

• Developers are forced to estimate everything. You can’t start/finish/deliver a story until it has been estimated first. As long as estimates are optional, they won’t be done consistently.

• Everyone has a decent idea of how much can be done over time. The velocity estimates aren’t perfect, of course, and that’s just fine. They don’t have to be perfect – they just have to be Good Enough. (For what it’s worth, our velocity over the last 4 weeks was 20, 15, 16, 17 – good enough that we can expect to do around 15-20 points/week.)

There are also some smart touches. For example, you can set the team strength for a given iteration – if half your team is going to be pulled off onto another project next week, or out of town at a conference, set the iteration strength to 50%. Tracker will halve the expected velocity. Or if you have another developer you can pull onto the project, increase the strength to 125%.

Of course, Tracker isn’t perfect. It isn’t particularly client (Product Owner) friendly; I’d love to see a dumbed-down interface that is less intimidating to non-technical clients, but still has all of the features that they need (prioritization, Accept/Reject). And I’m not exactly sure where the QA role fits into the process – there is no “Verified by QA” state, so QA either needs to usurp the Accept/Reject role, or needs to be responsible for Delivery (deployment).

I’m also not sure how well it will work on large/long projects. After 4 weeks of work, we’ve added a total of 250 stories to the system, and 100 are still active (unfinished). It’s working fine now. But if we had 6 months of work mapped out in the Icebox, it might be a little hard to find things.

But Pivotal is actively working on improving Tracker, and even if they weren’t, it’s already better than most bug trackers.

We may be looking for some help this summer (and beyond), so we put a Ruby Developer Wanted post on Craigslist. We’ve had great success with Craigslist in the past; we found two of our employees and two of our key contractors there. But of course, the signal to noise ratio is lower than we would like. We usually get form-letter offers from offshore developers offering .NET or Java skills (even though we specifically ask for local Ruby developers).

This last time, we got a priceless email from an applicant that I’ll call Ivan (not his real name). Ivan’s email started OK – “saw your Craigslist ad and I’m interested,” etc. Quickly, though, problems came to the surface.

• Ivan doesn’t do Ruby work. He’s mostly offering design, along with PHP and ASP.

• Second, Ivan won’t work onsite, even though he appears to have an area code in the Twin Cities.

• Third, Ivan doesn’t really appear to be looking to do any work himself. He is offering to subcontract the work to others. “I can staff as little as 1 part time, to as much as you need (50+ full time designers).”

This isn’t remarkable so far. I usually get a few of these when posting to Craigslist. But take a look at the next paragraph:

“Let me explain how we work a little bit here. I have system surveillance software installed on the computer which will send you an E-mail every X minutes with a screenshot of my computer (50k in size each). This way you can be sure that I am working on your project at the scheduled shift and you can see the quality of work as it is being produced. You can also use this to confirm that I came in on time to my shift, and left on time, etc…”

This is wrong for so many reasons.

1. I don’t wan’t to sift through X (10? 500?) screenshots every day to make sure that my contractors are doing their job. Nor do I have time. The reason we might need a contractor is that we’re too busy to do the work ourselves.

2. Seeing screenshots taken from someone’s computer just feels slimy, like an intrusion of privacy. Even if Ivan is sending them to me (instead of me stealing them from him), it is not something I want to do.

3. How absurdly easy would it be to fake something like this? Heck, it would probably be easier to fake it than to do it for real.

4. We don’t hire people based on the idea that they will sit at their desk for 8h/day. We hire people to get things done. This is a misdirected approach to productivity.

And of course, the only point that really matters:

5. Ivan has destroyed any sense of trust. He’s asking me to expect deceit, and giving me a means to protect myself against his deceit (and an unreliable one at that). There is no way in hell that I would work with a contractor who I didn’t trust, no matter how many screenshots he offers me.

As I think about it, trust is even more important than competence. I’d rather have a trustworthy employee who made mistakes than a genius who I didn’t trust. Fortunately for Slantwise, we’ve been able to find both. I don’t think I’ll break our streak by hiring Ivan.

We’ve used a daily stand-up meeting at Slantwise Design for almost a year, variously called our “stand-up,” or “scrum,” or “duck” (don’t ask). At about 10am every morning, the six of us at Slantwise get together for a short meeting to answer three questions:

1. What did I do yesterday?
2. What will I do today?
3. Are any obstacles keeping me from getting work done?

In theory, the meeting should be quick – maybe 10-15 minutes. In theory, it should facilitate communication, put everyone on the same page, strengthen our team, and drive our projects forward.

In practice, it hasn’t worked for us. So a few weeks ago we dropped our morning stand-up, for five reasons, which I’ll outline below.