I will assume that the "push" approach is not only direct, but also immediate.
(Like when someone comes up to you and says "hey, Joe, can we roll this later today?").
The "pull", on the other hand, is not only indirect, providing the queue as the go-between, but also delayed. Tasks might accumulate in the queue, waiting to be picked during the day, or waiting for a planning meeting.
Effective use of working memory
We humans have a limited working memory. Whenever someone comes up to us with a task, we have to load a bunch of stuff into our working memory, switching to the different problem domain. This takes time and brain power (I remember reading a study on how for some programmers task switching is a limited resource, they can only suffer a handful of such switches a day).
We need the working memory to think, the less of it we have for the task at hand, the worse our performance will be (cf), so lending some of it to discuss a different task is detrimental to whatever we have been working on.
Plus if a person managed to surprise us with the question, then we'll likely loose the current state altogether!
And trying to hold two things at once, the task we've been working on and the task we've been approached with, we're likely to botch the second one too. We might give inadequate attention and working memory to it, failing to estimate its complexity properly, to judge our aptitude, to grasp the context and the the whole picture, etc.
So the "pull" approach allows us to schedule our work better, accepting new tasks and task-related questions when our working memory is ready to hold them.
P.S. cf. http://blog.ninlabs.com/2013/01/programmer-interrupted/
Remaining in the Flow
Some of us can enter a state of hyperfocus called the Flow.
I think that Flow is about keeping a right balance between our cognitive and emotional parts. It's a tight loop where what we do will also make us excited, feeding into our creativity, a sense of discovery, fluency and whatever else motivates us.
That balance is very effective but also precarious.
Task assignment might be stressful. It forces a switch from the creative to the planning and managing brain. It breaks the Flow easily.
This might be why Schaffer lists the "Freedom from distractions" as one of requirements.
So the benefit of the "pull" approach is that we don't have to break anyone's Flow with it.
Easy going, less stressfull
Task assignment taps often into uncertainty. "Can I do this? Do I have the time? Will I want to work on this tomorrow? Are there consequences if I pass?" These and a lot of other questions might pop into someone's mind unbidden when one is asked to take a task.
Uncertainty is stressful. Some studies show that it's worse than pain.
Interestingly enough, subtle assignment ("Would you consider working on this with me?") can invite even more uncertainty into the picture.
Even stronger stressor is the lack of transparency. We are wired to survey the social environment around us. Whether consciously or not, we're gauging were we stand, how useful we are to the team and whether our relationships are secure. Some people are more anxious about it by default than others (cf), but security in relationships is one of our fundamental needs, along with food and procreation (cf).
The "pull" approach brings transparency into the team. We know what's going on, who's working on what tasks, what's being done and what's being delayed.
Direct task assignment, on the other hand, often happens under the carpet.
P.S. More on that psychological safety aspect in Duhigg, What Google learned from its quest to build perfect team.
Separation of concerns
As Dijkstra put it, it's worth "focusing one's attention upon some aspect".
Picking the tasks is definitely a separate aspect. Or rather a group of aspects. We should clarify and discuss the goals of the task, see if the task is really needed, gauge it's priority, draw some complexity estimates, analyze different ways of achieving the goal (Cialdini cites a study showing the companies methodically assessing the options and thinking about the risks of each are on average more successful that companies whose process consists of jumping into the fray).
The distribution of tasks during development is important, certainly worth the "intelligent thinking" that Dijkstra talks about.
The "pull" approach allows us to focus on these important concerns.
Catering to the workflow
Our brains are tuned by time and environment, as well as other cues. More often than not we would develop patterns of behavior to be triggered by these cues (cf. "cathexis"). You can think of it as prefetching.
This facilitates our activities.
The classic Scrum requires the daily meetings to happen at the same time. That not only helps people to be there, but also plays to the time and place cues, allowing our mind to optimize for the kind of activities that planning and task distribution entails.
More informed decisions
"Assigning tasks to people is an implicit claim that you (the assigner) know better than them (the assignees). Even if this is true, it is still easy for a person to take offence. However, most of the time it is not true. People know themselves best. People are best at assigning tasks to themselves. And therefore, having one person assigning tasks to other people almost always leads to sub-optimal work distribution among the members of a team." - Pitfall of Scrum: Assigning Tasks by Mishkin Berteig.
Everything is simple when we have just one developer. But as soon as we have two or more of them, we'll start making mistakes while assigning the tasks.
Suppose we have a developer who always worked on problem X, and we simply assign the X-related tasks to her. What could possibly go wrong?
Except, this developer might be suddenly busy, she might be no longer interested in problem X and facing a burn-out, you might be missing an opportunity for other developers to learn the system better, other developers might feel excluded, there might be less incentive to verify design decisions and cross-pollinate, there will be less interest in what's going on with X and thus less motivation coming from Fellowship, etc. A lot of pitfalls for a simple no-brainer, eh?
Developers aren't simplified robots, they really do know best when it comes to picking their tasks.
Escape from dominance and submission (TA)
The "push" approach usually assumes and needs an authority. It stratificates the team into assigners and assignees. This configuration will often bring into play the related patterns of the human psychology.
The assigners might grow close to the Parent ego-state of Transactional Analysis, which is "...essentially nonperceptive and noncognitive. It is simply a constant and sometimes arbitrary basis for decisions... It operates validly when adequate information for an Adult decision is not available, but in certain people, it operates in spite of adequate Adult information" (Claude Steiner).
In other words, the assigners might grow to expect to be followed, regardless of how arbitrary their decisions are.
The assignees might similarly assume the submissive outlook, or other configurations that are compatible with the Parent ego-state of the assigner. (cf. Robert C. Ginnett - Crews as Groups: Their Formation and their Leadership)
Attempts to break from this scheme might result in sudden conflict and confusion.
The "pull" approach is less risky in this regard, it tends to gravitate the team towards the conscious Adult ego-state instead of tapping into authority interplay bound to the Parent and Child ego-states.
Self-documenting
In order to present the tasks in the queue we often need to prepare them. Write a user story, create a tracker entry, pin a sticker onto a Kanban board.
This piece, even if short, might serve as a basis for task documentation. We can reference the tracker issue from the code, or add details to the task card on a board.
Prioritizing
When I was researching the effective time management, I found in some of the authors the thought that the most important part is having a way to rake out the unnecessary stuff.
Remove things you don't really need from your to-do lists and you'll suddenly find that there is indeed time for the stuff that's important.
A similar idea can be found when it comes to project management and prioritization. It might be critical, for the healthy project design and development, to have the WON'T priority. Saying no to the feature creep. Separating chaff from the wheat.
Now, this is very hard to do with the "push" approach. It's hard to say no when being assigned a task. If it's being assigned, we expect that it must be important (due to the very social interaction invested in the assignment). The tasks pile up in developer queues. Developers become perpetually busy and/or forgetful.
With the "pull" approach, the iterative planning in particular, the trimming comes naturally. The queued tasks compete against each other for the iteration. By being put against one another they develop a natural priority. Only a handful of the most important tasks are picked, in accordance with the iteration capacity constraints.
Built-in feedback
In Lean production there's a "stop the line" principle (cf): if something is wrong with your development pipeline, you better figure it out and fix it rather than blundering on and trying to ignore the issue.
With the "push" approach some problems are hard to discover. The task might lack sensemaking information, people might have no idea whatsoever why it's important, there might be little to go on with regarding the motivation, the task might be too large or too complex, etc etc, yet when the task is assigned, most developers will grind through it despite the obstacles. This might be a good thing. But when we want to improve the management, to remove the obstacles and "Build projects around motivated individuals", the stoic toil might work kind of backwards.
With the "pull" approach the essential feedback is built-in into the system. When you announce a task and nobody takes it, you know you have a problem.
Maybe the goal behind the task isn't clear, maybe it doesn't really needs to be implemented, maybe you've lost contact with the team, etc etc. Whatever it is, you have to "stop the line" and fix it.
Less micro-management
People tend to simplify. It's an essential coping mechanism (cf). "System 1 is prone to substituting a difficult question with a simpler one" (Thinking, Fast and Slow).
One of such simplifications is establishing whether in a given context we need to think for ourselves or whether we can simply follow somebody else decisions. We can't expect a developer to always choose between the two (because making that choice again and again is slow and not effective). It is more likely that she will assume either the self-organizing or the follower approach.
“The advantage which a commander thinks he can attain through continued personal intervention is largely illusory. By engaging in it he assumes a task that really belongs to others, whose effectiveness he thus destroys. He also multiplies his own tasks to a point where he can no longer fulfill the whole of them.” - Helmut von Moltke.
“The decisive factor, despite technology and weaponry, is the value of the individual soldier. … The battlefield requires soldiers who can think and act independently, who can make calculated, decisive and daring use of every situation and who understand that victory depends on each individual.” - Truppenführung (Wikipedia).
The "push" approach pushes developers towards being followers. If the management takes important decisions, handles important communication and time slicing, then most developers would start delegating these cognitive functions to the management.
Thus we see in practice that the "push" approach often leads to managers being swamped with various degrees of micro-management.
The "pull" approach, on the other hand, invites the team members to think for themselves. It is usually mentioned as a path towards the self-organizing teams.
Mind you, a self-organizing team still needs the leadership and management, but leadership time is spent on worthy subjects (motivation, sensemaking, establishing the goals and deadlines, clearing the path from the roadblocks, etc).
P.S. It must be noted that "pull" is not for everybody. It will only work if the team is compatible with it on the cultural level, if there is a great deal of trust and humility among its members and if the people are willing to take responsibility into their hands. As Valve's Handbook for new employees mentions, "pull" might need courage and knowledge "not to freak out".
