The Four Hour Sprint

If you want to talk about themes that have dominated the last year of my life, “agile” has got to be one of the most popular. It seems that everyone wants to be agile, and there’s a lot of debate about what that means, if anything. Agile software development is a group of software development methodologies that are based on iterative and incremental development. It comes in a variety of flavors, the most popular being Scrum.

If you’re familiar with Scrum you know the common traits:

• Release often: Success if based on shipping working product.
• Don’t release crap: Trim back the features and release something that works well, both for you and your customer.
• Iterate: This week you’ll do X, next week you’ll do Y, even if that means undoing X.

The mechanics of a successful agile team vary, commonly differentiated by the length of a sprint or iteration. After much tweaking I’ve found that the shorter the sprint the better. I’m currently working in four-hour sprints and here’s why you should too.

Incedental Reasons

• Four hours is about the amount of time you can spend in Starbucks without your ass going numb.
• Four hours is about the amount of time you can actually focus. Hunger is usually my biggest distraction.
• Four hours is about the amount of time your laptop battery will last without re-charging.

For Realzy Reasons

• You have to manage scope: When you measure your sprints in hours - not days - you have no choice but to seriously question the scope of what you’re doing. You have to ship something! So, get your shit together.
• You can’t write garbage code: Let’s face it, how much damage can you do to a codebase in four hours? If tests have to pass and a deployment has to happen you just don’t have time to fuck around.
• You’ll get realistic: Constraints breed creativity. You’ll come up with incredible solutions to deliver on your deadline.

I know, this won’t work for everyone. I’ve worked on projects where simply deploying was a four hour task in and of itself! That’s garbage. If this is you, put “make deployments easy” at the top of your to-do list. Maybe your part of a bigger team, where coordinating deployments can get tricky. Work towards building a team of branching ninjas that can compartmentalize features and releases.

We’re very simple creatures. Most projects, probably the one you’re working on right now, go over budget and over time. That’s because, as humans, we grossly overestimate what we’re capable of actually accomplishing. Don’t fight it! Break things down into chunks you can actually handle.