When something needs to be done, be it a new task or getting help with an existing one, a knee-jerk reaction I've often seen in the wild is finding a person to do it.

Here are some random examples of this:

"I need to see the logs, who do I talk to?"

"I want this patch to be merged, who can help me?"

"I want that button to behave differently, who's available to work on this?"

Sometimes people would assume that a single actor is always available and waiting to perform a particular task ("if I want to see the logs, I go to Josh, he'd always help me with that").

Other times people would assume that a single router is always available ("if I want something implemented, this manager, Bob, can always help me finding the right person for the job").

Sometimes the tasks will be assigned at random ("I get assigned to tasks randomly (kind of)" - Best way to divide & assign development work on projects?).

I think that this is colloquially known as "push".

On the other hand, some development methodologies (Lean, Scrum, Kanban) seem to prefer the "pull" approach, when instead of being handed to a particular person (and sometimes through a routing person) the tasks are queued somewhere (on a Kanban board, in a Scrum backlog, etc) to be picked up by the team members.

I wonder, what are the benefits of the "pull" approach? It might be useful to enumerate them.

  • Not sure - but I think there are two different problems here. The first is drive by tasking, which will destroy any team. The second is "how is intake allocated" which is a variation on change management.
    – MCW
    Commented Mar 16, 2020 at 14:29

5 Answers 5


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.


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.


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".


Pull approaches optimize for flow (how quickly tasks move from 'in progress' to 'done'), while push approaches optimize for 100% utilization (making sure everyone is doing something at all times).

Let's look at an example. We have two developers, A and B, and 8 tasks, 1-8, ordered by priority.

Push model:

We assign 1, 3 and 5 to A as well as 2, 4 and 6 to B, leaving 7 and 8 in the backlog.

  1. A completes 1.
  2. B completes 2.
  3. A completes 3. We assign 7 to A.
  4. A completes 5. Note that 5 was completed before 4. We assign 8 to A.
  5. B completes 4.
  6. B completes 6. B now has no work to do and is idle, so we dredge up low-priority task 9 and assign it to B.
  7. A completes 7.
  8. B completes 9. Gets assigned 10, the real bottom-of-the-barrel.
  9. B completes 10. After getting burned out working on tasks 9 and 10 which B knows no one ever actually wanted in the first place, B decides to not inform the assigner and instead sit idle.
  10. A completes 8.

Pull model:

We start with A working on 1, B working on 2.

  1. A completes 1, starts 3.
  2. B completes 2, starts 4.
  3. A completes 3, starts 5.
  4. A completes 5, starts 6.
  5. B completes 4, starts 7.
  6. A completes 6, starts 8.
  7. A completes 8. At this point, the only task among the first 8 being worked on is 7, by B. Ideally, A now works alongside B to get 7 finished asap.
  8. A completes 8.
  • 1
    But such perfect push micromanagement is only possible when the timing is rather predictable, isn't it? And in software development the timing is unpredictable more often than not. Plus most projects have more tasks than time, so the problem of someone staying without a task might be less of an issue.
    – ArtemGr
    Commented Apr 11, 2018 at 15:24
  • @ArtemGr No, the idea behind a push model is that management has some means of knowing when an employee finishes a task (such as the employee reporting this), at which point they assign a new task. The difference between the models is what happens when a task is completed. When a task is completed is irrelevant.
    – Sarov
    Commented Apr 11, 2018 at 15:29
  • Why the downvote?
    – Sarov
    Commented Apr 13, 2018 at 21:09

I’m assuming you are talking about small tasks. In that case, one advantage is that people who found themselves looking for work can take a task right away.

It seems like you are also requesting guidance on how to handle these requests:

I suggest you to have a well-defined process around how to make these requests and when to accept them. The easiest way to help you decide is having a “request template” that the requester needs to fill in in order for the request to be accepted. Some fields can be: what, why, description, suggested deadline, and any particular thing related to your domain problem. This helps them think if their request makes sense!

Monitoring and logging of these tasks is important to:

  • Understand clearly what can be actually done by the business
  • What impact they are having on the current deadlines
  • If you are working with a client, how much it’s costing them.
  • How much they are costing your company to see if there’s an adjustment necessary on the bill for the client
  • Last but not least: if the task is turning into a recurrent one, maybe it’s time to plan for automation

All non urgent requests should be analysed during the next sprint planning. Then you can assign it to someone depending on how busy they are going to be and then come back with a deadline.


The short answer is that we pay a high cost for interrupting people (context switching). If you want people to work efficiently, and to feel good about their work environment, then it is up to the PM, or the Agile equivalent (depending on the methodology--Scrum Master, whomever) to protect developers.

This isn't always politically possible. It is always preferred if productivity and good work are valued. And, sometimes emergencies occur and that interruption is essential. But, to repeat, pull is associated with significantly higher productivity and satisfaction.

Addendum: It is really bad for developers to be at the mercy of any stakeholder who has their contact info. Interruptions are disruptive (see longer answer above, or consider context switching), even when a new task doesn't result. Regardless of push or pull, the PM (or whomever) wants to be in a position to be the sole contact with stakeholders outside the team.


In my experience, software tasks often have both hidden dependencies and hidden contexts. You often find one developer "specializing" in this or that area of the system because (s)he is more familiar with it and can get the work done faster. Anyone else on the team should be familiar enough with any part of the system to "ramp up" on any area and get the right work done, but impromptu specialization is often more expedient. Obviously you need to encourage "stirring the pot" so that the left hands do know what the right hands are doing.

"Queueing" often works well, as long as you are aware of the patterns by which this queue might most-naturally be serviced. Be sure that the entire team always understands the urgency of each task and how it will advance the project as a whole. The team members themselves are often a most-excellent resource to help you make these decisions on their behalf, because they are "in it" every single day, and they possess technical knowledge and domain-specific experience that you may well not, and really would not be expected to have.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.