“Early Pain” over “Analysis Paralysis” or “Hurry Up and Wait”

Analysis Paralysis vs Hurry Up and Wait vs Early Pain

Analysis Paralysis expresses reluctance to proceed

Analysis Paralysis refers to excessive time spent on exploring a problem, and a reluctance, for whatever reason, to proceed to the next stage.

Analysis Paralysis

Traditionally, Analysis Paralysis is associated with waterfall processes, but we see an expression of this in iterative, incremental product delivery approaches as well.

As an example, using Spotify’s Think It, Build It, Ship It, Tweak It lifecycle, Analysis Paralysis would be spending too much time on Think It and not proceeding to Build It OR spending too much time on Build It trying to building the ultimate “MVP” and not proceeding to Ship It OR spending too much time at small % rollout exploring in Ship It and not proceeding to scale out to 100% (aka proceed to Tweak It).

NOTE: This does not mean every idea should proceed if it turns out the idea doesn’t work; it means that the go/no go decision should not be extended indefinitely.

To address Analysis Paralysis, you might take an approach of “just ship it”

Because Analysis Paralysis feels slow, a typical approach is to try to rush through and “just ship it”. What actually happens with this rushing approach is a phenomenon I’ll call Hurry Up and Wait.

Hurry Up and Wait

Hurry Up and Wait occurs when you defer, or even avoid discovery of, difficult, important problems in order to get started quickly, but this leads to stalling and/or chaos when the problems eventually appear and/or can’t be ignored.

As an example, using Spotify’s Think It, Build It, Ship It, Tweak It lifecycle, Hurry up and Wait would be rushing through Think It to start Build It and getting stalled because none of the dependent groups are on board OR having to cycle back to the drawing board repeatedly because of poor reasoning and insight.

Hurry Up and Wait is a common trap because, until that point of stalling occurs, it does actually feel very fast.

Early Pain is the fastest overall approach… but it’s painful.

My preferred, and, I believe, the actual fastest overall approach, is what Martin Fowler called Early Pain.

Instead of, “It doesn’t feel right to have these difficulties this early in the project”, your reflex should be, “Why aren’t we detecting any difficulties this early in the project?”

As an example, using Spotify’s Think It, Build It, Ship It, Tweak It lifecycle, Early Pain means Think It will be structured such that the highest priority product and/or technical risks are explored first. Early Pain also means Think It isn’t just deciding that the product is worth building but also includes getting input and feedback from all the groups that will need to be involved in building and shipping the product. This might involve some fairly difficult conversations and politics. This will influence how Build It and Ship It will be approached.

As you might guess from the name, the reason why Early Pain is not more common is because it’s painful early on. Until you’ve done it enough to form the habit, you need the discipline to overcome the desire to avoid the pain.

See also Conquer and Divide.

How do you know if it’s Early Pain or Analysis Paralysis or Hurry Up and Wait?

How to know whether you’re applying Early Pain, or just engaging in Analysis Paralysis or Hurry Up and Wait, is a complicated thing to describe. Here are some questions that I use to think about this:

  • What, if any, are the broader time constraints?
  • Will this actually improve end-to-end lead time?
  • Is this detail that can be deferred and worked out later?
  • Is this something that will cause a lot of unnecessary work if we don’t have a difficult conversation and/or get concrete feedback now?
  • Will talking more about this resolve anything or would it be faster to build something to test it?
  • What are the highest priority risks?
  • Do we have representation from every group who will be involved in getting this done? Are we missing a perspective that might highlight a risk (or opportunity) we’re not aware of?




Staff Agile Coach at Spotify, ex-ThoughtWorks, ex-CruiseControl

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Who will pay for Spectre? Probably you.

ARTEMIS.RED - Your friendly neighborhood Validator

Eaton recrute Plusieurs profils

Coding Standards in Java

Tips for Implementing a Software Release Process

Mod slot limit fallout 4

Top 10 Software Development Tools To Use In 2021

AWS ECS-Fargate with Cloud Formation

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Jason Yip

Jason Yip

Staff Agile Coach at Spotify, ex-ThoughtWorks, ex-CruiseControl

More from Medium

Guiding principle: the basic unit of product development is the team, not the individual

“We’re a team” but each person is playing a different sport. “I’m playing football”, “I’m playing baseball”, “I’m playing rugby”, “I’m playing basketball”, “I’m playing hockey”.

Schrödinger’s Estimation; Why Estimations Don’t Mean Anything

Project to Product nudges for large organisations

Is hybrid approach better than agile or traditional? #11