Getting Lean with Weekly Sprints

PV KS

In Scrum, sprints are time-boxed delivery cycles that help keep the team focused on the goal. If you don’t know which goal I’m referring to, check out Dr. Eliyahu M. Goldratt’s novel “The Goal” (hint: I think it’s something about making money).

For web development, I run weekly sprints and this surprises a lot of people – “How can you get anything done in just one week?” Truth be told, if I could, I’d run shorten this to daily cycles, but then I think it wouldn’t be Scrum anymore (Kanban, anyone?).

You’d be amazed what you can accomplish in a week – even if it’s only to convince your team that you should try your damnedest to ship one meaningful feature every 5 days. I want to challenge the idea that longer sprints help you get more done.

Time for Development

If your sprints are longer than one week, everyone does one of two things:

• relax because now there’s time to finish everything
• go nuts with new requirements because the developers are so relaxed

Pretty easy to spot the deadlock here, right?

Focus, focus, focus. Don’t work on three things at once. Just pick one story, one feature, or one bug at a time. If it’s too complex to finish in one week, break it down. It doesn’t have to be pixel perfect and fully functional in the first iteration. Release it in “stealth mode”, only visible to certain users or groups (or request params).

You’d be amazed how focused the discussion becomes once you have something running on the live site. Not a design template in Photoshop, or a screenshot mashup with some ugly red markups – “This is running on the live site now?” Shit just got real.

Time for Testing

Even two week sprints allows folks to start thinking in development and test cycles. We’ll code some crap together in week one and fix the bugs in week two. Sprint complete, right?

Wrong! What usually happens – of the six features you “finished” maybe two are actually releasable. The majority go right back into the next sprint cycle (for another hack and fix-fest).

One week sprints naturally limit your optimistic tendency to try and do “everything” and instead focus on just one thing at a time. Do everyone a favor and write some automated tests for the one thing you’re working on right now. Software engineering is a lot more than just hacking something together and pushing it off to QA.

Time for Deployment

If you had a month to develop a feature, you probably wouldn’t start thinking about integration. It’s just such a long way off – and what if your feature isn’t even ready by then? So you put your nose to the grind and start coding in your own little world for a few weeks.

And, just like that, the sprint is drawing to a close! Is your code tested? No? Well, when did you plan on deploying it? What do you mean you’re having trouble finishing it!?

One of the most overlooked and yet the most critical part of any software development process, there’s no point in coding anything if it isn’t shipped. Since most people naturally procrastinate, long sprints tend to cause a traffic jam as developers frantically try and get their changes deployed before the review.

What’s your sweet spot for sprint iteration length? How’s that been working for you? Share with us in the comments below.