Pull the Problem, Not Just the Task

Pull changed my relationship with Scrum because it moved responsibility closer to the person doing the work. The deeper opportunity is to pull responsibility for the unresolved problem, not merely the next prepared task.

My old Scrum blog carried a post called Trying Vs. Seeking Permission.

I had facilitated a team that was trying to remove process bottlenecks and deliver earlier. I proposed several directives for the team to own. After 2 Sprints produced only ordinary benefits, a team member asked whether one directive could be changed.

I replied that trying was better than asking for permission in an agile project.

The team changed the directive. Within a few more iterations, the result improved.

The episode contained a useful lesson. My wording gave it too much freedom from context.

A task can be pulled without responsibility moving

A team may pull cards from a backlog and still wait for permission whenever reality differs from the plan.

The task moves. Judgment does not.

That arrangement is comfortable for both sides. Management can say the team is self-managing because nobody assigned the card. The team can say it followed the process because it completed what was written.

The unresolved problem remains between them.

Real pull begins when someone notices that the prepared work will not produce the intended result and accepts responsibility for making that gap visible.

Initiative needs a boundary

The old advice can be misread as permission to bypass authority.

Some decisions expose customers, money, safety, privacy, legal obligations, reputation, or other people to consequences they did not accept. Initiative does not transfer those rights to the fastest actor.

Responsible action therefore needs a boundary.

Before changing the work, ask:

1. Is the action inside my decision rights?
2. Is it small enough to reverse or contain?
3. Are affected people able to see what is changing?
4. What evidence will tell us whether it helped?
5. Who carries the consequence if it fails?
6. Which condition requires explicit approval before action?

The purpose of these questions is not to rebuild permission-seeking around every move. It is to distinguish an experiment from an unauthorized transfer of risk.

Pull a hypothesis, not a hidden solution

When someone identifies a bottleneck, the first response is often to advocate a solution.

Change the tool. Remove the review. Add a person. Rewrite the workflow. Skip the control.

The stronger pull is to own the uncertainty first.

What condition is slowing the outcome? What do we believe causes it? What small change would produce evidence? What would make us restore the previous state?

This turns initiative into a visible bet rather than a private preference.

It also creates room for other people to contribute information the initiator does not have.

Make the experiment legible

The change my old team made worked within a facilitated setting, against an explicit objective, over observable iterations. It was not a secret act followed by a request for forgiveness.

That distinction matters.

A responsible experiment names:

• the problem being addressed;
• the current hypothesis;
• the bounded change;
• the people affected;
• the evidence to observe;
• the review point;
• the stop or rollback condition.

This is enough structure to make initiative accountable without turning every adjustment into an approval queue.

Escalation can be an act of ownership

Pulling the problem does not always mean solving it yourself.

The constraint may sit in architecture, policy, funding, staffing, incentives, or a decision owned elsewhere. Pretending to possess authority you do not have is not agency.

In those cases, ownership means carrying a precise problem to the level that can decide. Show the cost of the current condition, the evidence already available, the options, the consequence of delay, and the decision required.

An escalation that transfers anxiety upward is weak.

An escalation that makes a blocked decision possible is work.

From Scrum practice to project leadership

Scrum gave pull a visible mechanism. A Sprint Backlog belongs to the Developers, and the people doing the work decide how to turn selected work into an Increment.

Project leadership under uncertainty asks for a wider capability.

A forward professional does not wait to be pushed through every step. Nor do they treat initiative as personal sovereignty. They recognize a gap between intent and reality, establish what they can responsibly own, produce evidence, and bring the remaining decision to the right place.

The title matters less than the movement.

Pull the problem close enough to act.

Keep the consequence visible enough to remain accountable.