Finishing what you start makes teams more productive and predictable

I went through the video. For the HP example, their core issue was a quasi infinite backlog because they would add to the pile regardless of their velocity.

This looks to me to be a problem that is orthogonal to doing tasks in parallel or not: in the single task a time model, the extreme case would be an employee stuck on a single task without any lever to unlock it. Both scenarii are a failure of task management, and I'm not sure one is obviously better or less likely than the other. However you organize your tasks, you still have to manage your flow in one way or another.

My argument is, the amount of work in progress depends on the quality of your tickets, and not much about wether you allow "pipelines" or not.

> they start switching tasks and increase the amount of work in progress, which leads to even more blockage

Isn't your issue that none of the things in your backlog are effectively doable without blockage, and deciding to stick to a single task forever, or switching to many other ones might not actually have any effect on the output ?

I saw an egregious example of that in a contracting team, where one of the dev's job for a week was to go division B and request they unlock him. The rest of the time he was working on his personal project and reported "preparing the requirements for the next tasks of the sprint".

On switching tasks, I think it gets a bad rap because the worst cases are very simple to visualize: it's a pile. The reverse being nothing, and "nothing" isn't as exciting. The line doesn't go up.

I agree deadlines are a necessary evil to ensure we hold ourselves accountable to both customers and internal non-eng stakeholders who need to know when things will ship in order to make plans around them and collaborate with us effectively.

One approach to develop a healthy culture around deadlines I've been thinking about lately:

Plan the deadline around the minimal lovable product, while spec'ing out the minimal shippable product, and ensure there's enough of a delta between the two so we can have a large degree of freedom w.r.t. scope.

Without this freedom to vary scope, _when_ (not if) our estimates invariably fail, our only options would be to extend the deadline (defeating the purpose of setting deadlines in the first place if we resort to this often enough), or to burn ourselves out with overtime work in an attempt to meet those deadlines (obviously results in an unhealthy/unsustainable environment, and not even guaranteed to succeed).

It is also a rookie mistake to think that just because some tasks might blow up, you can't accurately estimate a large class of them to within a reasonable confidence window (say, within one day 99% of the time), and likewise identify those tasks with a large chance of blowing up. Breaking down tasks into smaller tasks seems to help build this skill faster in some people.

If you don't want to be a mindless drone, you should also see the need to practice skills beyond just cranking out code.

Where it really falls apart is that a restaurant has a predefined menu and no items are allowed to have unknown complexity (someone asking items out of menu just gets a “no”). Estimates are based on actual measures, not guesses.

There will be accidents, but those will be rare enough to not have to be planned for.

In that respect, a restaurant queue is a lot more akin to a factory, and is fundamentally different in nature.

That's because it chooses a bad example of an activity for which production-line methods make sense. Pick an activity (that you need to repeat many times) where each step requires quite different tools and skills that are difficult to master, and breaking it up into tasks for individuals who specialize in said tools/skills is almost certainly going to get you better throughput. Even in the letter-stuffing example, if you imagine that if it required full/focused use with both hands of different tools for a) folding the letter b) placing it in the envelope c) sealing the envelope d) stamping it, then having different people special in and handle each subtask, even if it means paying a bit of extra time for moving the item between each individual, is likely to pay off (of course, if one of those subtasks takes vastly longer than the others, it may need 10 people doing that, vs one on the others, but that doesn't change the principle).

Obviously software development is very different - we're not asked to use the same tool repeatedly to produce the exact same result. Further, in our world a) switching between tools is usually relatively costless and b) developers are generally quite capable of becoming skilled with multiple tools.

But I'd still say that some of the same principles could apply, e.g. if those assumptions weren't true for whatever reason (e.g. switching tools means physically moving to a different piece of hardware in a different room, or there are obvious measurable differences in the skills of your developers as far as particular tools go), then splitting a task up so one part can be handled by one developer with one tool and the other by another developer with a different tool is probably going get you a better result than asking one developer to be responsible for "finishing" the whole task themselves. Arguably the important thing is that they be on the same team and consider themselves to have a shared responsibility for the task that's been split up. Which interestingly, often isn't how teams are organised in software development companies, from what I've observed over the decades. Having an end-to-end feature be the responsibility of a single team, even if it necessarily requires multiple specialists, is probably not a bad guiding principle - but on the flip side, many peoples aren't (for understandable reasons) keen on being shuffled around between teams depending on what each feature requires.