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).

It’s voting day! And the region

It’s voting day! I’m kinda sad I didn’t get around to posting about amalgamation or the LRT, but neither of those issues are ending today, so there’ll be more time.

### This blog endorses Jane Mitchell and Sean Strickland for Regional Council and Ken Seiling for Regional Chair. ###

I’ve been particularly disappointed about how the campaign has turned around the LRT. The provincial government failed to come through with its promised commitment. The region will have to come up with the remaining $250 million (or thereabouts). Some wag did a back-of-the-envelope calculation and decided that that meant a 9.1% increase in property taxes to proceed.

Except no-one would ever agree to that. I don’t agree with that. I might be okay with a 9% increase in property taxes for myself to fund LRT, because I think it’s that important, but I’m not a senior on a fixed income the majority of whose wealth is tied up in their house.

So that would never happen. But increasing property taxes isn’t the only way a government can pay for things. And we aren’t dealing with a fixed price tag anyway. The plan can adapt.

We don’t know what we’re talking about until regional staff can get back with options. Everything that’s been said about LRT during this election has been useless because *we don’t know* what we’re dealing with.

It’s all incredibly disappointing.

I’m voting for the people who I think stand the best chance of building the region I most want to live in. Although I’m a bit sad that no-one except Ken Seiling has seriously stood up for the LRT plan they voted for.

Please vote today! Hopefully I’ve been a little bit helpful.