Day 1 at SD West

What we do follows us around.

Last year, I taught a mostly-successful half-day course at SD West, focusing on Ruby, Rails, and Ajax. "Mostly" successful, because I spent so much time on Ruby that I really didn't get to Ajax at all, let alone database migrations, testing, before_filters...oh, tons and tons of stuff. So I kind of cringed, chalked it up to a learning experience, and figured (A) plenty of people nevertheless got value out of the class and (B) anyway, it was now in the past.

Except today, one of my fellow West attendees recognized me. "Didn't you teach a class on Rails here last year?" I said "Yes" and ducked quickly, but he proceeded to say such nice things about it that I blush to repeat them here. When he got to "So, are you going to write a book or something?"...all right, that made my week and it's only Monday. I neglected to scope your badge, my friend, but it's YOUR FAULT I had so much trouble getting into my room tonight, my damned head kept getting wedged in the door. So thank you. And, yes, I'm seriously intending to write a book. I have two in mind, in fact, one on security and one explaining to outsiders just what the hell it is that we do, and how to take best advantage of it.

That kind of encounter is obviously enjoyable, but also chastening: It's really a big responsibility to be up there. If what you say is crap, at best you're wasting their extremely valuable time. At worst, they'll follow the garbage you gave them and REALLY get into trouble. One of the best things about writing for Software Development, God rest it, was that the readers were hair-triggered on the keyboards whenever their Bullshit Filters lit up.

I'm pleased to say that Johanna Rothman's half-day this morning was both very enjoyable -- I'd forgotten what fun she is to listen to -- and potentially quite useful for our team. "Predicting Project Completion" presented techniques for estimating projects in a fashion more useful than the S.W.A.G. (Scientific Wild-Ass Guess).

One good takeaway for me was "Schedule Games", all-too-common antipatterns of interactions between project managers and their higher-ups. I blushed to hear some of my own words in some of them, like We'll Go Faster Now, We Can't Say No, and 90% Done. (Though I meant to ask her what Pants On Fire and Happy Date were, if nothing else they would have been good for a laugh!)

Another one that we'll have to internalize is the necessity of measurement so that you can update your schedule as time goes on, and getting some idea of how your estimating is doing. I'm seriously thinking about deploying one of the nifty project-management tools I got via the Jolts this year (maybe Teamwork or Version1). Since our projects at UW usually have only one developer, and never more than three, these tools always seemed like overkill. But I'd really love to extract a little more detail than "I felt good" or "I feel guilty" out of our performance on any given project. And Johanna really, really is sold on the value of velocity charts, though I suppose one doesn't have to drag in a whole PM tool just to get those!

And today I finally grokked "relative sizing" and how it relates to durations -- thanks Johanna! Basically, the idea is that you sort your tasks (features, or user stories) into buckets based on your team's best estimate of their relative difficulty (do NOT try to express this as duration yet!). A Fibonacci sequence seems to work well: The tiniest things are 1s, 2s are twice as big, then you have 3s, 5s, 8s, 13s, 21. There's some question on how many bigger buckets to make after that, Johanna recommends 40, 60, 80, 100, where 100 stands for "too hard, you don't know anything about this one, break it down into smaller tasks".

Then you shake the list, ensuring that all the 2s look about the same size. (Why the 2s? Well, 1s tend to be less than a day, and so they're too teeny to be useful). Figure out about how many person-hours a 2 is, cut that in half, and you've got your scaling factor for each bin.