Pull processes do not only play an important role in lean approaches such as Kanban, they are also fundamental to Scrum: Applying the framework generates a pull process where teams pull work from the product backlog into the sprint. Understanding what a pull process is and how it works helps you apply Scrum and Kanban effectively.
The easiest way for me to illustrate the difference between push and pull is to evoke a childhood experience you may share with me: drying the dishes. I vividly remember being called into the kitchen after Sunday dinner where my mum had already piled up the clean wet dishes. Even though I would frantically try to reduce the size of the pile in front of me, I always ended up finishing off the job long after my mum had retreated to the living room together with the rest of the family.
Now imagine running cleaning and drying the dishes in pull mode. The first thing my mum and I would do is to agree on a small buffer of clean wet dishes, say three. I would then wait for my mum to populate the buffer. As long as the buffer is full, my mum is not able to clean any new dishes. Only once I have started drying one of the dishes, she would clean the next dish.
Establishing a pull process changes how work is carried out: It closely links formerly disjointed process steps; problems and impediments now surface quickly. A pull process eliminates waste such as partially done work (also called work-in-progress or WIP). What’s more, it creates a sustainable pace by avoiding overburden: In Scrum, the team determines how much work they can pull into the sprint and hence manages its own workload. In Kanban, WIP limits ensure that demand is matched to capacity.
Be aware that establishing pull usually involves disruptive change. It it requires that the people carrying out the work take on ownership and are empowered. Work can no longer be pushed onto anyone. It now has to be pulled along.
OKRs—objectives and key results—are a popular goal-setting technique. But can and should you use OKRs…
For any business to succeed, it is crucial to make the right strategic choices. To…
Being empowered can make all the difference in doing a great job. Sadly, not all…
Products often don’t exist in isolation. Instead, they are part of a product portfolio. Think…
Product discovery has become increasingly popular in recent years as a way to determine the…
Strong product leadership is crucial to offering successful products and enabling product-led growth. Unfortunately, there…
View Comments
I know that I am over 8 years late to this conversation. When trying to make small change to a product management group. Where is the best place to start? My first thought was to ask about organizing product backlogs rather than a giant portfolio backlog. Then, bring up a conversation about removing the product owner by proxy/glorified business analyst situation. However, after reading this post, my gut feel is to start with establishing a true pull process as the first step.
Thank you for your comment Tyson. I find it helpful to understand an organisation's goals and challenges in order to determine and prioritise the right improvement measures. If the development teams are overloaded with work, for example, or if people work on too many unrelated work items, then introducing a pull process like Scrum can be the right measures. But if product management is not recognised as a function in its own right, and product people don't receive the necessary support and trust form the organisation, then addressing this issue may be more important. Hope this helps!
I guess I have to agree that it is unusual that organisations have trust in pull. Actually classic project management is all about how you can push work around your company in the most clever way.
The distrust of the classical manager in the worker pulling instead of having a good time is similar to the distrust of him in a Scrum team committing to an ambitious sprint scope. ("Why shouldn't they just committ to Löw hinging fruits?")
>Be aware that establishing pull usually involves disruptive change.
That means that not only Scrum is disruptive but Kanban also and therefore it wouldn't be possible to implement Kanban in a totally evolutionary way?
I don't want to pretend to be a Kanban expert so I can't comment on if, when and how Kanban can be introduced evolutionary. But moving from push to pull has been a big change in all organisations I have worked with. If my mum, bless her heart, were used to pile up the wet dishes and to tell me to work harder and faster, then with a pull process in place, she is no longer able to do that. My mum now has to consider my ability to dry the dishes which effectively ties her work rate to mine. Say I was a lazy kid (which of course I was not ;-)) and I could not be bothered with helping my mum always waiting for her to make me do work, then employing pull would require me to take responsibility for my work and to be proactive: It's now my responsibility to pull new dishes out of the buffer and to get on with my work.