Scrum it's "PULL" or "PUSH" System?

What are the characteristics of a pull system, versus a push system, in your view? Might the limitation of Work In Progress be a significant determining factor? If so, how is WIP limited in Scrum?

In a PULL system, work is done only when available. The entrance fee is the same as the exit rate. I think the WIP limit is related to a PULL system. In Scrum, Sprint can be considered a WIP limit. Following this line of reasoning, Scrum is a PULL system, right?

Following this line of reasoning, Scrum is a PULL system, right?

That would seem reasonable.

Do you think the situation would change if a Scrum Team were to implement Kanban as a strategy? If so, in what way?

I think not. Because Scrum itself is already a pull system because it has the WIP limit (Sprint).

By using Kanban, we continue with Sprint, our WIP limit keeps happening, so we still have a pull system.

A Kanban strategy ought to result in better transparency over work in progress. If a team defines WIP limits and policies for where their workflow begins and ends, and assuming they own that workflow and can actively manage it, then pull might be improved further.

Hello, 

I am looking at Scrum with Supply Chain Management perspective while I am responding to this query.

The most prominent characteristic of a "PULL" system in classic SCM is the prominence and importance of feedback mechanism. While "PUSH" systems heavily rely on estimates, PULL systems consistently make amendments to the outputs depending on the feedback received.

Usually, typically in the Scrum, the Scrum Team is consistently receiving feedback internally (from within the dev. team and from PO and SM) during the sprint, while most of the external feedback is incorporated during the Sprint Review and Retrospectives. 

Due to this definitive nature of breakdown of feedback incorporation Scrum may appear to have both PULL and PUSH. But going back to the basics, since the work on the feedback is undertaken diligently (compared to PUSH system where it may not be since it can create conflicts with initial estimates), it is a PULL system. 

Thanks  

Hi,

I particularly interested in the topic. So, I would like to share my perspective in case anybody would like to discuss further.

Scrum itself has both PUSH and PULL characteristics.

Why Scrum has a PULL characteristic?

Considering when a Sprint begins, valuable-items that relevant to a Sprint Planning are selected and PULLed into a Sprint Backlog. If those can be done before a timebox ends, it gives a Development Team more room to consider if more valuable-items and/or urgent tasks can be PULLed in, or not.

Why Scrum has a PUSH characteristic?

When a new idea emerges and be accepted thorugh a Design Thinking process. It's then transformed into a User Story. And, be PUSHed into a Product Backlog waiting its chance to be pulled into a Sprint Blacklog in regard of its priority.

Does Scrum still has a PULL characteristic without Kanban implemented?

Considering that since the Sprint is a timebox event that valuable-items should be picked carefully in order to be able to achieveh within the specific time period. This sounds likely a WIP Limit introduced in Kanban practice, where it can be scoped to cover per an activity lane, per entire WIP boundary, or per a period of time upons a decision of the Scrum Team. So, having or having not the Kanban implemented, Scrum itself has a PULL characteristic.

Anyway, by having Kanban implemented, it helps the team to has a better visual represent on how valuable-items flow through a workflow.

Thammatee, 

I'm going to challenge you a bit on this statement. 

Why Scrum has a PUSH characteristic?

When a new idea emerges and be accepted thorugh a Design Thinking process. It's then transformed into a User Story. And, be PUSHed into a Product Backlog waiting its chance to be pulled into a Sprint Blacklog in regard of its priority.

If applied appropriately I think this can actually be a PULL method as well. If a new idea emerges the Product Owner does not necessarily have to put it on the Product Backlog. I'd argue that the Product Owner has the option to PULL the new idea or work onto the Product Backlog and then re-organize it from there. 

If you're setting up your Kanban lanes to have a 'Triage' of an idea then the Product Owner can choose to PULL it onto the Product Backlog or move it to something like a Parking Lot or just cancel the idea all together if it doesn't fit into the current goals of the Product. 

This can also help keep the Product Backlog lean and help increase focus during refinement. 

I'm going to agree with @Tony Divel's comments.  An I'm going to be a bit flippant with my answer but I believe it makes a case.  It is going to sound a bit like a bad joke but please humor me.

Two Product Owners are sitting at a table talking.  Antonio tells Ekani about an idea he had for his product.  Ekani looks at him and says "that is great idea. Where did it come from?".  Antonio replies "I just pushed it from thin air."  Doesn't sound right does it? It should be "...pulled it from thin air".

In your career how often have you seen things pushed upon a development team that ended well?  Sure sometimes it does but most of the time it ends in different degrees of bad. 

Assembly lines work based on a push model.  Software Development is not an assembly line even though for years it has been treated as such. 

The Scrum Guide never uses the words "push", "pull", "extract", "insert", "move", or "flow".  Any movement of items into the Product Backlog, Sprint Backlog or Increment is implied.  But if you read the guide the tone and discussion implicitly describes behaviors of pulling items through instead of pushing.  Based on my understanding I can't think of a single agile practice that uses push instead of pull. I will admit I might be wrong and would welcome someone that can better inform me. But I feel that pull always works better than push, not only in software development but life in general.

Thanks all - this is very useful.



I recently sat the PSK I exam, and unfortunately did not make the 85% pass mark. I am currently revising the suggested practice areas and hoping to pass again very soon.



Reading the arguments above - I think Scrum definitely contains elements that create a pull system. It might not be as truly flexible as Kanban, but there are enough gates and flow management already in place in the Scrum Framework.



As said above - the Sprint Backlog is an example of WIP. Also the ability and agreement to re-order the backlog ("moving tickets to the top") allows the team to dynamically respond to customer change.



Push systems are traditionally known as "Pile it high, sell it cheap" type models. An all you can eat food buffet, or a very basic manufacturing plant producing large quantities of product to keep costs down. When compared to these, Scrum is definitely more PULL than PUSH!

 

I was reviewing this topic and there is no exact conclusion, so is Scrum a "PULL" or a "PUSH" system?

My advice is not to bother about a conclusion. If you ever see work being pushed onto others, just wonder about Focus and Respect.