2010 in review

2010! All in all, I think it was a good year. Personally, I mean. I have some issues with it geopolitically, but I don’t think we need to go into that. And, for a change, it went by without any significant job turmoil. That’s something!

* Back in January, I got myself dragged into the long-running Northdale neighbourhood debate in the city of Waterloo. Not something I enjoyed greatly, but I felt I had to dip my oar in. I even [presented to city council](http://www.flyingsquirrel.ca/index.php/2010/01/13/my-delegation-to-waterloo-city-council/) about it.
* I was [interviewed](http://www.flyingsquirrel.ca/index.php/2010/03/25/local-transportation-stuff-and-the-100/) by the (now sadly podfaded) The 100 Podcast about transportation issues and the LRT. That’s kind of cool.
* I made a failed attempt at live coding for [Kwartzlab’s latest 5+5 event](http://kwartzlab.ca/blog/dw/2010-07-05/55-v2-rocked-out). Fun, though. And I’m glad I did it.
* [[Kwartzlab]] continues to be a great thing in our community, that I’m happy to be a part of.
* I ran an [[Ubuntu]] Global Jam, two release parties and helped host a LAN party with Eric. I started holding [Ubuntu Hours](http://wiki.ubuntu.com/Hour) in Kitchener-Waterloo and IRC meetings for Ubuntu Canada online. In the end, [txwikinger](http://blog.txwikinger.me.uk/) and I became the new “contacts” for the [Ubuntu Canada Local Community](http://ubuntu-ca.org) organization.
* I joined the office dodgeball team, leading to a number of minor injuries.
* I went to [Bill](http://thesidekick.ca) and Tara’s wedding. Eric and Alex get married tonight.
* I co-presented on unit testing with [Alexei](http://twitter.com/az1) at the local [agile software development group](https://waterlooagilelean.wordpress.com/). More live coding!
* Speaking of the Agile P2P, a number of us got together to start a technical [book club](http://agileclub.wikispaces.com/), starting with [Uncle Bob](http://www.objectmentor.com/omTeam/martin_r.html)’s [Clean Code](http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882). A number of agile development luminaries, including Uncle Bob, have joined our conversations.
* My blogging output flagged a bit, with everything else going on. I took out some of my local politics frustrations on the [[Waterloo-Wellington Bloggers]] Association, but that site is now defunct, merging with [Wonderful Waterloo](http://wonderfulwaterloo.com). That site has asked me to contribute as a blogger, but I haven’t pulled together a post yet.
* The new season of Doctor Who was awesome! I thought so, anyway. Also, I now have a ridiculous amount of Doctor Who toys.
* Ellen is still awesome.
* I became an uncle. My sister Erin’s son Grady was born in October.

The Marshmallow Test

As I was leaving for work yesterday, there was [an interview with a guy on The Current](http://www.cbc.ca/thecurrent/episode/2010/12/15/death-of-anticipation/) on CBC yesterday morning about the Marshmallow Test.

Basic premise is you sit a kid down in a room with a marshmallow and tell them that they can eat the marshmallow whenever they want. However, the experimenter tells them, if they can wait 15 minutes until the experimenter comes back, the kid gets another marshmallow. [[wiki:Deferred gratification]].

The [[wiki:Stanford marshmallow experiment|original Marshmallow experiment]] followed its subjects for twenty years. It found that the kids who were able to defer gratification were more likely to do significantly better in school, have more friends and were generally considered more competent. Whether or not you can hold off stuffing a marshmallow in your face for 15 minutes when you’re 4 years old is a strong predictor of success later in life.

Anna Maria Tremonti (the host of The Current) wanted to focus on what this means for kids today (*Kids today!*) with their twitters and facebooks and ended up glossing over the most significant thing in the interview.

The marshmallow test is predictive, but it’s not fatalistic. Impulse control can be learned. It can be taught.

More than that, we have this image of self-discipline being stiff-upper-lippedness. Stoic resistance to pleasure. But the kids in the marshmallow test who were successful were the ones who were able to “strategically allocate their attention.” They were able to use distractions–singing songs, running around the room, study the ceiling tiles–rather than agonize over not eating the marshmallow.

Falling down

So I left for work this morning, intending to walk to work as usual, braving uncleared sidewalks and bitter winds.

After [my fall on the ice a few years ago](http://www.flyingsquirrel.ca/index.php/2007/03/19/winters-final-crushing-blow/), I started using [Yaktrax](http://www.yaktrax.com/walker), which I highly recommend. They’re a bit of a pain to get on, though.

So I left my house this morning debating whether I should put the Yaktrax on. I’d fallen during a dodgeball game last week and jammed my shoulder, so reaching down to pull these rubber things on my boots would probably hurt. I’d walked to work plenty of times without a problem, and it was just packed snow, really. It didn’t look like there was much ice.

But then I started thinking it would really suck if I re-injured my shoulder.

And that’s when I fell.

Damage seems to be minor. I landed on my knee first and went down slowly. But I’m going to see if I can book an appointment with my chiropractor today to make sure everything’s back where it should be.

Have I mentioned I hate winter?

Why track velocity?

Say you’re on an agile software development team and your Customer doesn’t care about release planning or even whether you make your commitment in an iteration. You’re a good team and he’s confident you’ll get the work done when it needs to get done.

Is there still value in tracking velocity? If your customer doesn’t care, is it worth the time to create burn-down charts?

[Burndown! OMG!]

### You can’t manage what you don’t measure. ###

Velocity tells you how much work your team can do in an iteration–say one or two weeks. It’s based on two things: how many discreet items of work you completed and the unitless “size” of those items, as determined by the team themselves, often a long time ago.

Knowing velocity has three separate benefits for the team, regardless of whether anyone else is interested in seeing that number:

1. It can be motivating for people who want to try to improve that number,
2. It tells you how much work your team is likely be able to complete in a subsequent iteration, and
3. It gives you feedback to improve the “size” estimates.

Motivation is great, but the biggest benefit I see is the future iteration planning one. A big part of iteration planning is having the team “commit” to a bundle of work. You can spit-ball an estimate, but software estimation is notoriously hard to get right. Having velocity takes away a lot of the guess-work. It’s not perfect–changes in the team and errors in estimation make the number less reliable. You’re not looking at a precise, hour by hour estimate, however. You just want to have a reasonable amount of confidence in the amount of work you can do on aggregate. Velocity gives you that.

Making your commitment for an iteration is good discipline even if, again, no-one else cares. As a professional, you should be able to finish what you said you’d finish when you said you’d finish. Fortunately, knowing velocity helps you with that.

One of the compelling things about agile for me is the automatic feedback mechanisms. If you plan more work than you’re able to do, your velocity goes down and your next iteration should be more manageable. If you plan too little, and you’re able to take some work off the backlog, your velocity goes up, so you’ll automatically do more next time. Eventually, you find an equilibrium.

Likewise, if you tend to overestimate the “size” of work, your velocity will be high. “Size” has no direct relationship to time besides velocity. Any future estimates you make knowing previous size and velocity will be somewhat improved over your initial, somewhat arbitrary estimates because you now have a better yardstick to measure work by.

Your first iterations are almost certain to be unsuccessful, because you don’t know velocity and you have poor estimates. If you work the process, however, your estimates will improve and you start to have a hope of making your commitments. And it’s much more fun when you’re winning a game than when you’re losing all the time.

If you’re interested in delving deeper, [James Shore does a way better job explaining this stuff than I can](http://jamesshore.com/Agile-Book/estimating.html).