…aaaand we’re back, after six 80-hour work weeks in rapid succession. Here’s to rediscovering a more sustainable pace and getting back to writing regularly.

“Small batches” have been on my mind a lot lately. Eric Ries discusses the concept in his Lean Startup book. The basic idea is to do repetitive work in small end-to-end batches, creating one finished product at a time, rather than in large batches where you create many products at once in a phased manner. He credits the concept to Toyota, and applies it in turn to startups. Here’s a real-world example from his book of a race on stuffing envelopes between a father and his two daughters:

The daughters, age six and nine, knew how they should go about completing the project: “Daddy, first you should fold all of the newsletters. Then you should attach the seal. Then you should put on the stamps.” Their father wanted to do it the counterintuitive way: complete each envelope one at a time. They told him “that wouldn’t be efficient!” So he and his daughters each took half the envelopes and competed to see who would finish first. … The father won the race, and not just because he is an adult.

Ries cites many benefits to doing work in small batches, including less waste, less inventory, earlier discovery of defects, and a tighter feedback loop. I’ve found all these to hold true in doing software development. I happen to be focused on web services, but I see no reason these benefits wouldn’t also hold true for many other kinds of software and creative production work.

When not writing code I’m often planning what work we should do next, and I’m finding the small batch philosophy yields benefits on planning too. Here’s an example: we made a change on CampusPerks a week ago to our planning granularity. We used to estimate our work in half-day units, equating 1 Pivotal Tracker “point” to 4 estimated developer hours. Now we equate 1 point to 1 estimated developer hour. Sounds simple, right? You might think it would have little to no effect, but in fact after only a week I can already see a few significant benefits:

• We’re estimating our work with greater precision, and there’s a 1:1 mapping between estimated points of work and available developer hours. So questions like, “Can you get feature X done by Wednesday?” have become easier to answer (i.e. less time-consuming, with smaller error bars).
• We can now give credit for smaller pieces of work… the sort of stuff we might have assigned zero points to in the past because it took an hour or less to do, or lumped together with 4 or 5 similarly-sized items into a 1-point story. I find this especially true of design work, the fit-and-finish and attention to detail that is essential for making a product beautiful, but that often doesn’t get the full respect it’s due. Being able to give credit for all work regardless of its size feels more equitable to me and, I suspect, makes everyone on the team happier.
• It’s easier to decide how to fill small chunks of available work time. If I have an hour before lunch I can take 10 seconds to pick the next 1-point item off the backlog, knowing that I’m likely to complete it before my energy fizzles. In the past I might have wasted 5 or even 10 minutes hunting for a small-enough work item.
• My motivation to begin a new work item is higher, because none of the tasks look as daunting now (everything is scoped in hours, not half-days or days), I’m more certain of how long each task will take, I get to check off tasks more frequently, and I almost always get the satisfaction of carrying the baton across the finish line on tasks that I start.
• All this leads to more time when I can reach a state of flow.

The fact that chunking work in this way motivates me more and helps me reach flow was a delightful surprise, so much so that I’ve applied the same 1-point-equals-1-hour change to the other software projects I work on. It isn’t just accounting or semantics; there’s a real psychological difference. The bottom line is I find myself more willing and able to work if I invest the time up front in batching the work into smaller units. The work is easier to begin, faster to complete, and more satisfying to perform.