How do you respond to uncertainty?

February 23, 2022
If we're in the business of developing software, we're going to face uncertainty. Are you able and willing to embrace this?

How do you respond to uncertainty?

I recently asked you to ponder this question.

What did you come up with?

I believe that the “Agile Industrial Complex” approaches this question in one way, whereas “small-a agile” approaches it differently. And how you respond to the question will likely determine which approach you find to be more appealing.

Of course, there’s room for plenty of nuance in answering the question, but I think there are roughly two ways to answer it. Think of them as ends of a spectrum.

At one end of the spectrum we have the mindset of conquering uncertainty: collect more data, do more analysis, better education, improve understanding to reduce or eliminate uncertainty, require extra checks, implement more robust control structures.

At the other end of the spectrum we have the mindset of embracing uncertainty: prepare for anything, defer commitment, exercise real options, promote localized empowerment for faster response, eliminate control structures.

I expect by now you can see where I’m going with this.

“Big-A Agile” is often about conquering uncertainty. More planning. More estimation. More procedure. More control. Less autonomy.

These things are in stark contrast with the tone we get from the Manifesto: Individuals over processes, collaboration over contracts, responding to change over a plan.

Now I don’t believe either end of the spectrum is inherently better or worse. Sometimes we need to conquer uncertainty. Sometimes we need to embrace it.

But in the world of software development, a certain amount of uncertainty is inherent, and cannot be conquered. Other aspects of software development are uncertain due to constantly changing market conditions.

As long as we’re in the business of developing software, we’re going to face this reality. How does this make you feel? Are you able and willing to embrace this uncertainty, even if it’s scary, and offers little in the way of guarantees? Or are you more comfortable holding on to notions of tidy release schedules, defined requirements, better estimates, and false guarantees of certainty, and a lagging market response?

This is the red pill/blue pill moment. To liberally paraphrase Morpheus:

You take the blue pill—the story ends, you wake up in your bed, and believe whatever you want to believe about tidy software plans and schedules. You take the red pill—you stay in Wonderland, and you get to explore how deep the uncertainty hole goes, and find creative ways to embrace it.

Share this

Related Content

Don't become complacent

If a thing helps you, use it. But don't become complacent.

No running!

By calling iterations "Sprints", Scrum implies a need for constant running. Don't be fooled.

"Agile" isn't about delivering every sprint

Frequently delivering software, but not considering feedback on how to improve, isn't agile.