Pull is often seen as an attribute of Kanban, but it’s something that needs to be present in almost every agile team, regardless of their chosen working practices.

As work progresses through the system — from a concept in somebody’s head to working software in front of the user — it needs to be pulled from one step to another.

It’s quite common though for work to be ‘pushed’ in some key areas. The impact that pushing work will have varies across teams and products, but it can be anticipated as being synonymous to pushing work in Kanban: amongst other things it risks creating bottlenecks while providing no guarantee that anybody even cares that the work is done.

Here’s three key areas to consider:
1. The development team pull work from the Product Backlog during Sprint Planning. Nobody, should have pre-selected the work prior to this session. This is of course distinct from prioritisation, which is the responsibility of the Product Owner, and any other backlog refinement activities.
2. Product Owners (and customers) should be pulling work to production. It may be the engineer who pushes the button, but it should be initiated by demand. If nobody is pulling the work then there is nothing to suggest that the work was valuable.
3. There is a caveat around information radiators, such as Sprint Boards or any progress updates that a Product Owner shares. Things should be transparent across the team and the business and this is unlikely to be achieved if information is only made public when it is explicitly asked for — in this case, the organisation’s value of openness and transparency is the pulling force. Transparency is a value, while ‘pull’ is a practice. Values should always trump practices.