What is the difference between push vs pull?
In a pull system, teams pull tasks from the backlog. As opposed to a push system where work is pushed onto the team. To demonstrate the effects of push vs. pull we can use Black Friday as a useful analogy.
Generally, on Black Friday, shoppers rush to the store after Thanksgiving dinner. When the doors finally open, everyone rushes into the store to get to the bargains they are after.
The shop floor becomes especially overloaded, and everyone stops moving while they wait or fight their way through the clog to get their hands on the product they want.
Figure 1: Overloaded Resources inside the System
Shoppers make their way through clogged aisles, busy intersections, and other piles of great bargains, slowing down at each one. Eventually they find their way to the cashier line. Then they really wait - for hours – literally. They eventually make it out the door again and on to the next store, or home because who wants to go through all of that again?
The push at the system level is generated by the customers walking in the door. More customers are added to the store "system" with no regard to how many are already there. There is no controlled limit to the number of shoppers allowed inside the system simultaneously. The physical limit is the only limit, and it is reached only when the system is so full that pretty much everything in it stops moving.
Because there are so many overloaded resources in the system--for example, the cashiers--each shopper's time inside the system is much longer.
The shoppers on Black Friday are the work in the system: the projects, sub-projects, and tasks in our product development system. The cashiers, aisles, and intersections are our engineers, designers, test technicians, and other scarce product development resources.
Wherever our resources are overloaded with too much work, the work is slowed down. The more projects, sub-projects and tasks we simultaneously load onto the resources, the more clogged up they become, and the longer it takes to get the projects through.
Black Friday illustrates the cost of ‘push’ at the system level. But it could be even worse, if we didn’t use a pull system at the most critical resources in the system – the cashiers.
To illustrate pull and push at the resource level, we look at a single resource. Let’s start with an aisle resource where there is no controlled limit to the number of shoppers sharing that aisle.
Once traffic in the aisle reaches a threshold, every new shopper added without another one leaving clogs up the aisle a little more, which slows down some or all of the shoppers a little more. By the time there are ten shoppers sharing a ten meter aisle, they are close to gridlock.
A resource processing multiple tasks simultaneously and thereby delaying the completion of some or all of those tasks is called multitasking. Note, our definition of multitasking has at its core the necessary condition that some tasks are slowed down by the presence of other tasks. When a resource simultaneously processes multiple tasks, but none of those tasks are slowed or degraded in any way, that is not multitasking by our definition.
In contrast to the multitasking aisles and intersections, cashier resources use a pull system and Work In Process (WIP) constraints to single-task (work on one task at a time). When the current shopper is done, they pull the next one in line and process the next shopper, and so on.
Figure 2: Pull System
This picture indicates a long wait because the critical resources are so overloaded, but it could be a whole lot worse. Can you imagine what it would be like if the cashiers operated in push mode, and multitasked across all of the shoppers in line? They would scan one product from the first shopper, then one from the second shopper, then one from the third, and so on through everyone in line. Then they go back to the first shopper and scan his next product. Every time they switch shoppers, a little time would be spent in the process of switching. How long would our shoppers wait in the checkout line line then?
Imagine if every time we went to a store, for example, the local grocery store, the cashiers multitasked? If, on average, there are 3 people in line at a time, our average check out time would triple, from 5 minutes to 15 minutes: and that is before adding the switching costs. In the picture above, with twenty people in line, every hour a shopper spends in line in normal 'pull mode' would become a whole day in 'push mode'. Black Friday would need to be renamed Black Friday, Saturday, and Sunday.
The first person in line really gets delayed, and the last one is also delayed because of all of the wasted time spent switching between everyone in front of him. Everyone would be frustrated – the shoppers, the cashiers, and the managers. At least until they get used to it and start to believe “that’s just the way it's done.”
Fortunately, when we can see the work – like we can see the shoppers and their purchases – we more naturally converge on using pull system. But when we can’t see the work, the opposite often happens and resource-level ‘push’ systems very often result.
This is what is happening in our typical, push-based development systems. The work in the system is very difficult to see without some form of Visual Work Management tools, and even then, unless we have the really good tools, we only get to see some of the work.
The result is that the resources are overloaded and multitasking, and the durations of their tasks are unnecessarily extended. Instead of the ‘single piece flow’ as demonstrated by the cashier example, we have multitasking as depicted in the image below.
Figure 3: The Costs of Multitasking
There is more to discuss about this image, and multitasking in general, which I will cover in the next post. In the meantime, let’s review the other key ingredients in a good resource-level pull system.
We’ve already touched on two key ingredients of an effective resource-level pull system – visible work, and work in progress constraints. Cashiers have a work in progress constraint of 1. However, simply saying ‘only work on one at a time’ is not sufficient. Consider this busy airport counter:
Figure 4: Busy airport
How easy is it for this resource to work on only one at a time? How often are they coerced to multitask? To achieve pull, we must also have tools that help make it happen. The cash register at the grocery store can only process one order at a time, and the checkout lane is only 1 person wide. These tools help force WIP constraints and limit costly multitasking.
But even visible work, work in progress constraints, and tools that encourage pull are not sufficient. These tools must also work in tandem with a supportive culture.
Also, the way people react to the situation can either support the pull system or it can degrade it. For example, if our shoppers expect or demand to be served when they arrive, rather than patiently waiting their turn, the cashiers and counter workers will multitask at least a little. It is human nature to want to help someone who is clamoring for it. But it usually slows everyone down.
The same is true of our product development resources. Visible work is the first step, and at least some form of work in progress constraints must be applied, which requires the right tools to really make it happen. Last, but definitely not least, the culture must support the desired behavior.
This brings us to another key ingredient to an effective resource-level pull system which we will cover in the next post – Clear, Common, and Correct priorities. In the post after that, we’ll look at the last key ingredient in a resource-level pull system – the use of project buffers instead of task buffers.
Stay tuned…
In Part 7 we discuss the adverse impacts of multitasking and we look at the value of effective pull systems and their key components: clear, common, and correct priorities.
----
Ready to learn two paradigm shifting concepts around what causes late projects? It's not what you think.
Lean project management
Lean project management methodology
Lean project management Kanban
Lean project management principles
Resource management
Pull vs. push
Task management
Shared project buffers
Decentralized planning
Daily stand-up meetings
Guide to Lean Project Management
