This article uses the analogy of a burger chef to show how software teams can be more productive by focusing on a small number of features at a time.
I think this is more widely applicable. The factory production line was designed to make already-designed things with the fewest mistakes. It does not make people happy, nor does it foster creativity.
Figuring out problems is hard. It’s kind of what I do for a living. Having lots of different things on the go at the same time does not improve things, it makes each one worse.
Now that we understand the burger and the software variations of the problem, we can make a recommendation to both cooks and software engineers alike:
Reducing transaction costs enables small batches. Small batches, in turn, reduce average cycle times, diminish risk, and enhance reliability.
You should only start without having finished when transaction costs are high, and it wouldn’t make economic sense to spend time decreasing them, either because you have agreed to a particular delivery date or because you don’t have the capital to invest.
That said, I’d be careful to avoid falling into a situation where “you’re too busy draining the flood to be able to fix the leak”. The earlier you decrease transaction costs, the earlier you’ll be reaping the benefits from having done it.