Need for Speed: One-Week Sprints

A project I participated in recently ran one-week development sprints. It’s the first time that I worked in such short cycles, and I like it for similar reasons that I like Twitter with its 140 character limit: strong constraints force you to make tough decisions, to get to the core of things quickly, and to surface problems early.

On twitter, there’s no space for babble, for color, for flowery language: you have to get to the point quickly. One-week sprints are similar. In a one-week sprint, where you spend about half a day to a day altogether in all sorts of ceremonies (dailies, planning, sprint review, retrospective), so you effectively have 4 days left. If you assume to have 6 effective hours of work per day that allows for 24 effective hours to do “real work.”

Imagine a giant clock on the wall (time-bomb style) that is ticking down from 24h to 0h (there should be some TV drama based on that concept!).

Tick tock tick tock.

Now you really get the sense of urgency, we have to get going!

If you’re that constrained on time, what will you decide to spend your time on?

Do you just start to write code (or as some people call it: “real work”), or spend an hour or two planning the work with other developers? Of course, every hour you spend meeting in a five-developer team (like ours), costs you five hours total. Is that a good use of time?

It’s very easy to just jump into a sprint without much planning, and only then figure out that in order for you to start your task, Jimmy has to finish his, which in turn relies on an answer from the client to some ambiguous requirement.

As counter-intuitive as it may seem to some, sometimes it really pays off to spend an hour or two of collective time in a meeting to ensure that 5 people can work as independently as possible without blocking each other. What I see in practice is that how quickly you get to the desired end-result often depends on how well the work was planned in advance. Yet, many developers still consider time spent in a planning meeting as time wasted — as time “not doing work.” I don’t get this myself. Our job is to run towards the finish line as effectively as possible. That involves many things, only one of which is typing code into a text box.

But I digress.

On the other hand, what many developer do like is sit together and discuss technical issues: What framework shall we use? Shall we deploy this using Docker? Will this scale up to 5 million users? That’s the stuff we like to talk about. Sadly, the clock is ticking five times as fast whenever we sit altogether discussing such things too.

So the questions we have to ask ourselves constantly whenever there is something to talk about are these:

  1. Is this important? If we have two possible directions and we’d flip a coin, would the decision be significantly worse? You’d be surprised about how often interesting topics are actually not important at all.
  2. Is it valuable to discuss this altogether? If it’s not important to discuss this with the whole team (expensive!) perhaps we can limit the group something smaller.
  3. Is it urgent? For instance: will we deploy this in a Docker container? That’s important, but not relevant until we go to production which is one or two months. We don’t have to worry about it now, let’s worry about it when it becomes more urgent.

Forcing your mind to switch to “urgency mode” you really change your perspective on what matters, and what does not. Jack Bauer (let’s use this name as a placeholder for my hypothetical TV drama idea) is always in a hurry, he is always doing important stuff and forced decisions. The same applies to all of us. We should all be like Jack. Time optimization is always an important thing to keep an eye on, but if you have 3 weeks to deliver something, who cares if we waste another few hours talking about irrelevant things, right?

For this reason I like one week sprints. It’s a good exercise that will help everybody focus on what really matters. Perhaps we should try one-day sprints next?