Google Ventures does a lot of research on sprints. What they don’t say directly is that a sprint is a tightly constrained by time. In five days you have to decide, build, test, and iterate a new idea.

After building software for nearly ten years, I’ve come to the realization that the thing that drives both my ability to deliver software is being constrained. As soon as I believe that I have “free time” and can still be successful I tend to find failure. I run my team in one week sprints to focus on what we need to do in simple, themed five day bundles of work (sprint).

Gone are the days of waterfall and with that deadlines in the far future. Some Agile pundits believe that deadlines are bad. I actually disagree. I agree that deadlines six months away are bad but a deadline in five days is powerful. You can feel the constraint of time. Five days away is on the horizon, you can mentally grasp a weeks worth of work. You cannot grasp twenty four weeks of work. Can you wrap your mind around planning a dinner out in a few days? How about planning one in a few months? You will immediately start thinking about solutions to this weeks deadline, but you’ll naturally tend to put off the deadline months away. This is the true power of constraining yourself, and your teams.

Don’t be cheap

Cheapness is natural when thinking about constraining. We can shave off this work, and that work because it doesn’t fit the model. I am not suggesting you skip the hard stuff because it doesn’t fit in to your environment. Do the tough stuff but break it up into consumable chunks of time. As an example, we are rebuilding our permissions system. We are moving from a RDBMS to a graph. We spent a one week sprint on choosing what graph store to use, one week on building a proof of concept, and will now spend one week on taking that PoC turning it into an MVP we can test with a subset of our users. Hopefully after a week of testing, and monitoring we will release it to our entire customer base. The entire project took five weeks but we broke it up into sprints to constrain us. We were able to take a fairly complicated piece of work, break it down into week long challenges, and are tackling each. We are forced to attack each bit with our best creative problem solving skills.

You will need to have clearly defined success, and failure metrics. Find what is important, and what you think is realistic. Trust the people around you to take ownership of getting across the finish line. Perhaps if you can’t decide on the storage engine after a full week of work you are solving the wrong problem. This will all depend on your team, and its makeup.

Read the book by GV on Sprints. It will help you think about your team’s cadence and how you can be more consistent. It’ll also help you decentralize the problem solving. Everyone will feel like an integral part of the successes and failures. They will clearly understand the problem before them — one week instead of twenty four weeks!