KEEP IN TOUCH

Join Newsletter

CALL NOW

Share with:


Recent Posts





A “Free Hand” At the Bagel Shop (and, On Software Project Estimation)

Although it doesn’t seem very related to software project estimation, there’s a bagel shop I go to where the staff does something uneventful but effective after they take my order. Once written down, the cashier yells out “free hand.” The first time I heard it I wasn’t sure if I was missing something, if she was talking to me perhaps, or if there were a secret language of bagel staff employees that I didn’t know about.

At this small, family-owned bagel & eggs deli in the Brooklyn neighborhood where I live (La Bagel Delightshown here), I will get a bacon, egg & cheese on a plain bagel. This event — predictable— isn’t something you’d normally notice or mention. But this bit about them saying “free hand” reminds me of scrum software.

Picture 3 bagel workers and a line of 10 customers. Each order takes maybe 1 minute to 4 minutes, depending on whether it involves toasting, eggs, or other preparation. In this bagel shop, no worker is specialized— that is, there’s no one dedicated person to one kind of sandwich preparation. All of the workers take each new job indiscriminately. (We might call this a “homogenous” team, and no, we’re not talking about them being gay.)

You’d think maybe the workers could “double-up” the jobs: take 2 or 3 jobs and run them concurrently. For example, a customer with many sandwiches in an order. It could take upwards of several minutes to complete this order.

In the meantime, if the worker has a lot of extra time while they are waiting for the bread to toast, they might come back to the queue to take the next job. In this scenario— I find myself empathizing— I would imagine the worker must make his own queue — that is, a queue within a queue.

His queue is: 1) the first order which is toasting (last time we checked), and 2) the new order he just picked up. Interestingly, like software project estimation in some ways, I imagine preparing bagels (toasting, buttering, making eggs, slicing cheese, layering with topping, etc) is similar. The worker must manage several wait states. These are times when he or she must stop and wait for something or someone else. In both arenas, the length of time it takes to complete some parts of the task will be a fixed length of time (like the time it takes to toast). Other parts will take a length of time proportional to the size of the request. Still other parts will take an unusual, unexpectedly long time. A “snag”—for example, what happens when the egg salad is not made? If the egg salad isn’t made, the customer might have to wait up to 10 minutes. Who’s gonna make this egg salad? Put a pin in that and I’ll get back to that question in a second. Other than the fixed costs and the unusually long costs (both can create wait states) what else is there?

How does this apply to Software Project Estimation

In software project estimation, Excluding the unknowns (those wait states and unusual unexpected snags), one can reasonably say the length of time or level of effort to create a bagel (or piece of software) will be proportional to the size of the request. (Number of toppings or features.)

In software, we face these kinds of things too. The build time for a compiled program, for example, can be thought of as fixed (typically). For a software project with code tests, the length of time to run the tests (like continuous integration) can be thought of as fixed time costs too.

Hopefully, your software development doesn’t have unusually long costs. I’ll bet the guy working at the bagel shop doesn’t want those either. You see, the egg salad not being made is analogous to the comps or design specs not being prepared for a highly visual UX. Or worse, the design specs being made but the feature set being ill-defined.

Wait States in Software Projects

When a developer has a “free hand,” that means they have time and attention to pay attention to your problem or the next problem on the backlog. That problem — which really is the company’s problem— should be ready-to-go (without blockers, back & forth, etc). This way, the story (software development) can move through the queue as quickly as at a bagel shop like La Bagel Delight.

That’s why a good bagel store manager and a good software product manager remove blockers. The bagel store manager notices when the egg salad is low and makes more. The product manager foresees the blocker the software developer will have and removes it before it becomes a blocker.

“Free hand” is what the cashier calls out to ask if there is an available resource to take the next job. It’s a signal of the establishment’s demand and of the queue moving.

It turns out, that while it’s easy to suspect that like in the bagel shop, a ‘free hand’ can take 2 or 3 jobs at once, this is often a pitfall.

Why? Think of the whole system as a machine. If each cog has to manage its own internal queue of wait states, you will create a lot of task switching.

Task switching is your enemy!

Having lots of “single queued” developers who switch tasks all day long is, fundamentally, anti-scrum. By doing this, the product manager creates muri (Japanese for “waste of overburden”).

An efficient system is the only way to scale up. In both software development and a small food store, we see common elements:

  • Jobs come in one by one (or sometimes many orders from one individual)
  • Each job takes a varying amount of time to complete

Although it is tempting to manage this scrum-within-scrum, it is the path to hell. The reason for this is more obvious in software than it is at the bagel shop. There’s no good reason for long wait states. It’s best when a story isn’t ready for the developers to put the story back onto the backlog (or someone else’s backlog) and move onto the next one.

If you take one thing away from this article it is that you should reduce muda (Japanse for “value-reducing waste”) by eliminating blockers as quickly as possible. In this way, you will bring the work back into the main branch (in Git terminology) in a quick, iterative fashion. Ideally, your development work is deployed to production as iteratively and quickly as possible, too. That’s how you know you have a clear definition of done.

Remember, always have a quick stand-up at regular intervals. Stand-up is always about 1) What you accomplished yesterday, 2) What you’re working on today, and 3) Anything that is blocking you. Most importantly, a ritual stand-up is when blockers can be removed. (Remember, stand-up is not a management meeting, which I wrote a post about last year.)

Be like the bagel shop and always look for the team’s greatest need: Is the egg salad low? Let’s make some egg salad. If not, maybe go to the front of the queue and be the ‘free hand’ that will take the next job.

No Comments

Leave a Comment