The traditional method for building software says that you build the whole thing in one, big batch: use design the whole thing, then build it, then test it, then launch it. But recently the Lean and Agile movements have emerged, and both focus on building small batches and releasing small increments. So why have both of these paradigm-shifting movements chosen the same focus?
The simple is answer: because it works.
What Is a Large Batch?
As you can probably guess the idea of batch size comes from traditional manufacturing, but it can be applied to just about any job. Let’s take one that Eric Reiss talks about in his seminal work The Lean Startup and that administrators and marketers alike dread: the mass mailing.
Why Small Batches Are So Efficient
You’ve got a pile of flyers in front of you; a pile of envelopes; a pile of address labels; and a pile of stamps. How do you approach getting all the flyers into the envelopes and the labels and stamps on? You’ve got two choices:
-
Fold all of the flyers, put them all into envelopers, seal all the envelopes, stick on all the address labels, then stamp them all. This gets everything done in one large batch
-
Complete one envelope at a time. This means you’ll have lots of small batches
Which do you go for? Most people’s intuition says that doing the same repetitive task over and over is pretty efficient, so if you’re like them then you would say the first.
Here’s the problem with that approach. What if your colleague accidentally bought envelopes that are too small? If you’re doing everything in one large batch you won’t discover the envelope issue until after you’ve folded all the flyers. Or what if the envelopes don’t seal properly? Then you’ll have folded all the flyers and stuffed all the envelopes, so now you’ve got to unstuff all of them.
That’s the problem with large batch processes: if there’s anything wrong in a step you won’t find that out until you complete all the other steps.
But even if there’s no problems the single large batch process is still inefficient. That’s because our brains aren’t great at working out efficiency, and they forget that if you make a big pile of flyers and a big pile of envelopes you’re going to have to move stuff around. That moving stuff takes time.
On the other hand with the small batch you will only have folded one flyer before you discover the small envelopes, and only stuffed one envelope before you discover the defective seal. You’ll only be making one big pile of completed envelopes, so you’ll only have one pile to move around. This means that whether there are problems or not, this task will be finished much faster if you work in small batches.
(People have actually done this envelope-stuffing task under scientific conditions. That’s great because it gives the story credence, but you do have to wonder about how much time they have on their hands.)
Large Batches in Software Building
You can take the same approach with building software. You can scope the whole piece of work in one go, then design it, develop it all, test it all, then launch it all as one big batch. Or you can go the Agile way, releasing small increments regularly. The former – more traditional – approach suffers from the same problems as our mass mailing example, but amplified because it might take a year rather than a day.
Let’s say there’s a problem with the staging environment we’re launching. If we build everything in one batch we won’t find this out until perhaps nine months into the project. But if we’re releasing in small batches we’ll find out after perhaps ten days.
Even worse, what if the requirements for the software change? This happens pretty regularly, so we need to be able to deal with it. These changes normally happen when stakeholders see the product for the first time and have their own perspectives on it, and can be pretty severe. So if we’ve taken nine months to get to that stage we’ve got a bit of a problem; and we’ve got a project that’s going to run over on time, so we’ve also got an unhappy client, and on budget, so we’ve got an unhappy MD. But if we use a small batch process then stakeholders get involved after only a couple of weeks, giving us much less to rework.
How Does This Help Me?
Whatever industry you’re in you can benefit from focusing on delivering many small batches instead of few, large batches. If you’re writing copy on lots of different pages in a CMS try looking at your copy after you’ve done the first page then again after you’ve done your second page, instead of looking over it all at the end; if you find any problems you’ll only have one page to amend, not one hundred. If you’re building a new ecommerce website try adding a few products in their entirety and checking them, rather than adding the copy for all of them, then the images, and so on; if there are any software problems or process chokepoints you’ll find them much more quickly.
There are lots of opportunities to make your own life easier and your customers happier by moving to small batch processes. The best way to work out how doing this can help you, find something you take a long time working on. Then think about the process and how you can break it down. Start trying to do it in lots of smaller batches instead, and see the improvements start to come in.