They're called sprints because they're fast.

Agile development is designed for quality and flexibility. The fact that it's also highly efficient is a bonus. There's a huge variance in developer efficiency, even among capable and motivated people, and the combination of Rails and a strong process means that we really get things done.

Sprint planning

On the surface, planning out and committing to a one-week sprint is about giving the product owner - the client - some certainty about what they'll be able to ship. But as a developer, it provides a powerful focus.

Taking this to the extreme, I was able to write Relentless Memory in a matter of hours because I knew exactly what I wanted to build, why, and how I was going to do it. And this was under adverse circumstances: normally my early mornings aren't good for anything but drinking tea and reading Hacker News while I wait to wake up, but with narrow, clear direction they became highly productive.

It makes sense. When you commit to an action, all the focus that was being used to make the decision is suddenly set free and available to manage the execution. If you're still wondering whether the action is the right one, you'll execute poorly.

Rails

It's possible to take this a step further. Deciding what to do is one thing, something that's handled well by sprint planning. But, coding, I've also been hung up on how to do something. If I can see three different ways to carry out a task, it takes me longer to decide which is better than to implement any of them - or sometimes, all three.

Even while executing one of them, I'll be slower than normal, while I use scarce mental resources to second-guess myself, always ready to bail out and try a new angle if the going gets hard.

This is one of the reasons I find the Rails framework so powerful. Often there's one obvious way - the Rails way - to achieve something. Whether or not it's much better than the alternatives, not having to decide makes me much more efficient. And with good testing practice, it's easy to go back and change things later anyway.

Task breakdowns

But a proper process can also help here. Sprint planning can be followed by a 'technical breakdown' - taking the now-fleshed-out stories and working out exactly how they will be implemented. One way is to create a task card (much smaller than stories and without obvious business value), like "Write TokenAuth.verify_token method (1 hr)" or "Update login view html/css to include third option (2 hrs)". There'll still be decisions to be made along the way (because perfectly specifying the code is the same as writing the code), but having the team make the major ones as a group, in a single session, reduces the amount of context-switching.

Looking at my own work, it's clear to me that how I set up and manage the work makes a huge difference, probably more than any other factor. Our process is mostly about building the right project, and building the project right. These are still the most important results, but it's nice to know that it also helps us build the project right now.