Tuesday, August 21, 2012

How fast can you run?

I've been doing the agile thing for ages.  My first real programming gig was for a guy who had a background in manufacturing so we were doing Kanban and Kaizen before people were lumping it all under the single banner of Agile.  I've worked with no fixed cadence and I've worked with two and four week sprints.  I've never worked a single week sprint.  Until now.  I'll never go back.

Everywhere I've worked before, whether I was managing the team or otherwise, the team as a whole would collectively decide on the most comfortable cadence and go with that.  Most of the literature I've read seems to think this is a good idea.  If not a good idea, at least not a patently bad idea.  But consider this.  If I were to fill a room with random people and took their vitals, how much of their body mass would be fat?  A fair amount I'd wager.  Then ask them to start running together everyday.  What pace would they choose at first? Slow.  Pin whatever number you want to that word but the reality would be a pace not much quicker than a fast walk.

Now what if those people ran together five days a week for a year? 5 years? 10? They would be lean.  They would be running and often sprinting.  The problem with software processes is that slow sprint cadences get institutionalized and rarely once a pace is chosen does the team try to go faster.  Oh sure.  Occasionally there will be an urgent problem or feature that the team will have to push through quickly  but overall they'll be moving fairly slowly through a process bloated with overhead they don't know is unnecessary because they aren't moving fast enough to feel how much it hurts to carry the extra weight.

I speak from experience.  I recently joined a start-up where I get to help drive decisions like this.  As an experiment I asked the team to try running one week sprints to see what happened.  I asked them to hang with it for two months to see if we could make it work.  The first month was painful. We made mistakes.  We broke sprints.  But what we found was as we challenged our assumptions about how the dev process should work an interesting thing happened.  Rather than defending how much time we thought we needed to test a build for a sprint we found ourselves pushing more and more of our testing into continuous integration tests.  Rather than insisting we needed longer meetings to spin up or close out a sprint we found ourselves cutting out conversations which didn't get us deliverable demonstrable value.

I know what you're thinking. "By having twice as many sprints aren't we doubling our overhead?" Well, you can go that route, but then you're missing the whole point.  Yes. You'll be having more meetings, but it will be about half as many stories.  You'll be twice as focused because you'll have half the distractions.  The tendency to slack at the beginning and cram at the end will vanish.  It's easier to focus in meetings that are half as long. You'll spread out your test time more evenly rather than jamming it in at the end because you'll have to and your quality will improve. Suddenly CI becomes a necessity and CD becomes a possibility.  What I'm trying to say here is the effect of doubling your sprints is equivalent to cutting your diet in half and seeing your effective caloric intake drop to a third.  And that's one way that the fitness metaphor breaks down.  In life when we want to cut out a lot of fat it takes determination but it also takes A LOT OF TIME.  With your development process, as long as the whole team is on board it takes determination, but tremendous positive effects can be felt as quickly as two or three single week sprints. You get back more than you cut out because all the focus and efficiency that creates work TOGETHER.  Want specifics?  You can find more here and here.  But don't stop there.  Hit the Google.

One more thing worth pointing out is that when I say work faster I'm not talking about working 16 hour days 7 days a week.  I'm talking about increasing sprint cadence and efficiency.  If you've been in this dev game for decades we see few reasons why you'd have an excuse for going slower than two weeks. Sure if you need to transition from four to two before you can switch from two to one we'll cut you some slack, but you can do it.  And you should.

It's been three months.  We couldn't be happier.  Before this experiment I would have considered a one week sprint a pipe dream.  Having gotten our team to run smoothly on one week sprints, having cut out so much overhead, it makes you want to achieve even more.  We feel like a room full of former fatties on the fitness infomercials. Running a marathon is easy. For us, Continuous Delivery is no longer an impossible goal.  Like I've read with other teams that have gotten down to one week you wish you could shrink the cycle down to a day.  The urge is strong.  You want to go farther, faster, now.

So for those of you out there considering your options in terms of sprint size, or contemplating smaller sprints, there is no time like the present.  Stick with it.  It will be hard at first.  Push through the pain.  You'll be glad you did.  There is no reason not to go faster and you'll be much healthier for it.


  1. Another great benefit: When you start 'sprinting' more at work, you find that you 'sprint' more in other activities. After a few successes, you will want to push yourself in other areas to be more effective & efficient. Great post!

    1. You're absolutely right. I find that when the process is working well at work that I literally want to run out of the office. The urge to hit the street to cycle or run is strong. Time to climb the Matterhorn!

  2. Parkinson's law: Work expands to fill the time available to do it. Or something like that. :)

    1. Exactly. By keeping the process lean and the cycles short you virtually eliminate the natural human tendency to spend all day on Facebook and Pinterest. :)