There are tasks which will take some people half, or a quarter, or a tenth the time that some other people would take.
And there are tasks which only a few people can do. (If you get to a point where there are tasks only one person can do, you need to fix this immediately.)
In a small team (relative to the size of the project), the most critical requirement is triage: figuring out who could do this task, then how important it is relative to other tasks. Assigning tasks to the wrong people can kill everyone's productivity. Misjudging priority can kill the business.
The coffeeshop analogy is too strained. Think of it this way: does your group use a bug tracking system or a ticket tracking system? One is for development, the other for support.
I thought the analogy was appropriate. Like the author said, the purpose of the article is to provide a metaphor for software development we can study in real life. I don't think the intention was to create a directly accurate comparison.
There are tasks which will take some people half, or a quarter, or a tenth the time that some other people would take.
And there are tasks which only a few people can do. (If you get to a point where there are tasks only one person can do, you need to fix this immediately.)
In a small team (relative to the size of the project), the most critical requirement is triage: figuring out who could do this task, then how important it is relative to other tasks. Assigning tasks to the wrong people can kill everyone's productivity. Misjudging priority can kill the business.
The coffeeshop analogy is too strained. Think of it this way: does your group use a bug tracking system or a ticket tracking system? One is for development, the other for support.