This is a post about me not wanting to wait for ice cream. But it’s also about software delivery, I promise.

My wife and I had an ice cream craving a couple of weeks ago. We walked through the doors of the Ben and Jerry’s to find a huge group of teenagers queued up. Apparently, schools had just announced a snow closing for the next day, opening up a free night for thousands of kids. (Yes! Ice cream in the winter.)

It’s funny that we naturally anticipate the impacts of batch size in many everyday situations, but can’t see them in software development.

You instinctively know that when a little league team shows up just before you at the ice cream shop, or when someone at the office prints 35 copies of their 10 page workshop handout ahead of the 1 page resume you want to print, you’re going to wait longer than you normally would.

It’s just obvious.

The ice cream scooper person isn’t scooping ice cream any slower. The printer isn’t printing fewer pages per minute. Yet the time between when you get in line and when you get that ice cream cone – the cycle time – is significantly longer when there’s a large batch of work ahead of you.

In an ideal world you’d switch the order, right? You can satisfy one customer request quickly then move on to the bigger batch of work. The person waiting is much happier and the people with the bigger batch don’t actually end up waiting noticeably longer than they otherwise would have. And the total time to serve everyone hasn’t changed at all.

The problem detecting these types of incoming problems with software is that the work is usually invisible. We don’t have a line of teenagers in front of us or a printer console displaying “page 8 of 350”.

So what do we do? Well, we start by making the work visible. All of the work. The stuff in progress, the stuff queued up, the stuff in the “backlog”. Simple index cards on a wall work amazingly well. Many teams will run out of space – an amazing visual cue that the card sitting sad and lonely at the end of the list isn’t going to see the light of day for months.

Whereas we couldn’t cut in front of all the people waiting in line for ice cream, in software we can do whatever we want. When we see big chunks of work coming up we can make a decision to break it down or reprioritize something smaller first. I love weighted shortest job first for this. You don’t even have to be precise to make this simple process work. If you’re roughly correct most of the time, you’ll be miles ahead of most other teams.

These are shifts that take no training, no formal process changes, no team reorgs, no financial investment, but provide incredible value. The throughput (or velocity, or whatever) of the team doesn’t change at all, but the cycle time shrinks drastically. That means happier customers.

And that’s how you get ice cream in your belly faster.

[ad name=”Footer”]