One of the distinct differences between traditional project management and agile project management is the difference between "pull" and "push" tasks, processes or activities.
- PUSH paradigm - "let me plan out all the things that need to be done over a period of time, do them, and deliver the results to the customers." Let me PUSH the results I planned to you
- PULL paradigm - "find my customer and ask her what she needs at what time and ONLY do that work, even though I may think there are other things to do. Unless she asks for them, I won't do them." Let me have you PULL from me the results you need in the order you need them. (You do have to give me advance notice on what you need so I can build it).
The PUSH approach produces outcomes that COULD be used by the customers of the project. The PULL approach produces outcomes that WILL be used by the customers.
PULL is agile. PUSH is less agile. The exact units of measure between these two approaches is not clear. What is clear is the thought process for planning. In PUSH the planners have to think of an exhaustive list of deliverables. If its not in the plan up front, then its not budgeted, scheduled, resource loaded and the like.
In PULL, there is some planning but it starts with the customer needs and continues with the customer needs. Nothing is generated that is not explicitly asked for by the customer. The customer PULLs the deliverables from the supplier. It's KANBAN for tasks.
"This is obvious," you say. Its breathtaking how project managers plan deliverables in the absence of PULL customer input. Even when working with agile organizations, the PULL approach is not always used. The national - possibly genetic - approach is to make a list of what I personally think needs to be done, put it in the plan, define the budget, and resources, and start down the path.
Think PULL next time you're asked to make a plan. "What do you need and when do you need it," are the operative words of PULL. Then question every need and you'll be on your way to agile, lean, adaptive, iterative, and incremental.
A Thought on the behavioral environment of PUSH v. PULL
Much of the frustration with agile planning and execution comes from not accepting that PULL is going on in the customer environment. Providers of PUSH processes seek to plan ahead all the things that are needed to satisfy the customer. When the customer naturally makes changes to this list, the providers invoke the "change control" card. This is a natural response to the PUSH worlds view that "you've defined what you need, now I'll provide it."
In the PULL behavioral environment, there is an explicit understanding that change will happen. In fact change is desired and desirable, since it means the customer is adapting to the first order needs of the market.
But there is a dark side. It's called churn. If the customer "churns" the needs then the supplier is also churned by these needs. The result is the lowering of the productive output of the provider. There is a line over which PULL becomes CHURN. Where that line is and how the provider deals with the customer once the line is crossed is a complex and likely in tractable problem.
Is PULL Better than PUSH?
Depends on which side of the CHURN line you're on. This is the role of Project and Program Management. Keep the project as close to the CHURN line as possible for the cultural, economic, technical, safety, and risk metrics as possible. Cross the line and chaos ensues. Move away from the line and wasted effort ensues.
This is why we have Project and Program Management.
