Professional Scrum & Kanban Trainer
Licensed by ProKanban.org
& Scrum.org

No Longer Tolerate ‘Blocked’ or ‘Waiting’ States

1 Month ago, I shared a thought at LinkedIn and the response was significant. It’s nice to see widespread agreement that this one, simple…

Posted: January 24, 2021

1 Month ago, I shared a thought at LinkedIn and the response was significant. It’s nice to see widespread agreement that this one, simple principle has such positive impact.

I believe this principle strikes a chord with people, partly because everyone knows the pain of delay and shares the frustration — but, more interestingly, because the solutions are so elusive. A few people have since contacted me privately to discuss. So, I’ve decided to publish more insights and experience on the subject.

A screenshot of the LinkedIn post and commenters Visit LinkedIn to join the original discussion.

Advice: ‘Blocked’ and ‘Waiting’ Have Distinct Meanings

Blocked

Work is blocked when a dependency (organizational obstacle or dysfunction) prevents progress.

Example: Imagine a relay race: we’ve passed the baton to the next runner but their manager assigned them to a weight-lifting project instead of our track-and-field project. Our baton sits idle on the gym floor.

Waiting

Work is waiting when progress occurs and our attention, but not our direct effort, is required.

Example: Imagine a winery: we’ve pressed the grapes and primary fermentation is complete; now we keep the mixture in cold storage for six months as time softens the texture and the wine steals flavour from the oak barrel. (But if we wait too long, the ingredients will spoil. Our attention is still required.)

Example: Imagine we’re constructing a road. And it rained all night. If we continue our work in the current condition, we’ll make matters worse and cause ourselves more work & expense. We’d better wait.

Example: Imagine a sales pitch: we’ve presented our service and price to the potential customer, but the choice whether to proceed is not ours to make.

I don’t use these two terms interchangeably. Work that is blocked ought to be treated differently than work that is waiting. In a relay race, obviously we want perfect coordination and alignment among runners. Considering the art of wine-making, we may be happy to wait. Fermentation and aging take time, right? The act of waiting adds value to our product — the passage of time is the stategy. (But, does that mean we should continue to tolerate such a long process? Aren’t wine-makers actively experimenting with new methods to speed-up the fermentation and aging processes?)

How to Spot the Problem?

It’s difficult to see blocked or waiting work, particularly in knowledge-work environments.

Perhaps a piece of work is taking longer than expected? Perhaps team members report tasks A, B, and C are “still in progress” but it’s not clear whether effort is being exerted (and whose), whether said effort is moving the work forward.

Overflow storage of electric motors

In the manufacturing of physical products, stacks of inventory are a clear sign of blockage. Imagine a storage warehouse filled with used electric motors — we have plans to refurbish those parts and resell them for profit. Strangely, it’s our habit to look at stacks of idle inventory and see only the potential profit — “when we finally get those parts out the door, we’re sure to make a pretty penny”, we think to ourselves.

Unfortunately, those parts sit idle — maybe we’re paying a lease on the warehouse; maybe we’ve leased a 2nd warehouse. Perhaps it’s too easy to confuse potential profit with unrealized gain? Those conditions are very different, especially when what we really have are carrying costs.

In knowledge-work environments, the same phenomena occur but blocked or waiting work looks very different. Rather than warehouses filled with inventory, we might see:

Observable BehaviourConsideration
People shuffling between work groups.What’s preventing them from being 100% allocated to a single team, single project?
Planning meetings to discuss the priority of defects/bugs.What’s preventing us from simply fixing those defects?
Backlog items older than the hills.Which items took precedent, or were prioritized ahead of these? (Capacity is never the problem; it’s always a matter of priority!)
Team members report repeatedly: “I messaged the team lead in (department name) for an update.”Why are we dependent on that group? Are they actively working on it? If not, why are their priorities not aligned with ours?

Or perhaps we have a stack of projects in the 5-year plan. Again, it’s easy to think those projects are potential profit. “When we finally launch those projects, we’re sure to make (or save) a pretty penny”, we think to ourselves.

But, David, it doesn’t cost anything to have a project listed in the 5-year plan. It’s not like we’re paying a lease on a warehouse to store the project — it’s not like a stack of inventory.

That’s correct only if the project idea has never been pencilled into a fiscal record. 🤣 But project ideas aren’t without cost: perhaps budgets have been spent (e.g. feasibility studies, high-level planning); let’s remember how easy it is to write expenses against expected revenues long before a project is released.

What Causes Work to Stop or Wait?

Message: Stop Waiting
  • Lack of inventory
    • Supplier issues
    • Employee availability
  • Processes take time
    • Long setups
    • Poor scheduling
    • Communication problems
  • Defects
    • Quality problems
    • Bugs
    • Machine downtime
  • Overproduction
    • Over-processing
    • Oversized batches
  • Motion
    • Transportation
    • Unecessary repetition

Quantifying the Cost of Delay?

The cost of both types of delay is arguably the same. Whether we are waiting for wine to age, or blocked by competing priorities, the fact of the matter is we are prevented the luxury of delivery our work into the hands of customers. The only difference, perhaps, is that the value of wine increases with age — waiting may pay off if we can charge a higher price for the refined product.

To illustrate the cost of delay (and the benefit of early delivery), I like the age-old wisdom of financial advisors:

It is better to invest small amounts frequently, than bulk sums infrequently. The first reason relates to interest: the earlier your money is invested, the earlier the interest begins to compound. The second reason relates to market fluctation: frequent deposits have the effect of mitigating against short-term fluctuations in market price.

And for more thoughts about the cost of delay (the benefit of early delivery), I’m reminded of an article I shared in 2015: A Lean Startup is Going to Eat Your Lunch

How to Remove Such Obstacles?

Message: Difficult roads lead to beautiful destinations

As a first step, refer to the advice above: ‘Blocked’ and ‘Waiting’ have distinct meanings. Until we acknowledge and treat those conditions differently, we aren’t likely to apply an appropriate remedy to each.

And here’s some good news: while there are countless causes of delay, the solutions can be narrowed to just these few strategies. As follows:

Break the dependency

Maybe there’s no need for the dependency. An alternate technique or implementation may negate the need for said dependency. (This reminds me of another article: A Scrum Team Increases Their Velocity by Doing Less Work')

Establish authority within the team

Maybe the team already possesses the skill/technique required, but doesn’t yet possess the authority to act on it.

Develop skill within the team

Maybe the team relies on others because they lack specific skill. Good news, humans are good learners.

Negotiate a better SLA (Service-level Agreement)

Often, competing priorities and organizational misalignment can be rectified (in due time) by establishing clear agreements between groups. If group ‘A’ is not meeting the needs of group ‘B’, then clearly some negotiation must occur.

If you have insights to share, please use the comment below. I’d enjoy hearing your stories, strategies, and advice.

David Sabine
David Sabine
Professional Scrum Trainer
Professional Kanban Trainer

© 2001–2021 by David Sabine