If you’ve been reading this blog for awhile, you’ve probably noticed that accepting uncertainty is a a recurring theme when it comes to Agile and agility.  While it’s never stated outright as a “value” in either the Agile Manifesto or the Twelve Principles of Agile, the concept itself underlies many of the points made in those documents.  In my opinion, it’s the primary cultural distinction between organizations that still cling to the old, outdated “waterfall” approaches.  Waterfall creates a false sense of security by defining everything possible up-front.  Agile accepts that we don’t always know everything, and that new information will not only be discovered, but might alter the path.  Here are a few specific reasons why accepting uncertainty is essential for teams to be successful.

Accepting Uncertainty is Realistic

No battle plan survives contact with the enemy, as the saying goes — and no BUFR spec survives contact with reality.
– The Clever PM, apologies to Helmut von Moltke the Elder

First and foremost, nearly all development teams intuitively understand that software development simply isn’t an exact science.  Sometimes things that appear “easy” on their face take time, effort, and energy to fully understand and to build — and there’s almost no way in hell that someone who’s not a developer is going to be able to predict these things months before the teams encounter them.  Even in new product development, decisions made early on might not wind up causing complexity until much later in the project — which is the number one failure of “waterfall” and big up-front requirements (“BUFR”) approaches.  When we attempt to define everything up-front, and then hold people accountable to a plan that was established long before the project actually began (and often without much, if any involvement by the people actually doing the work), it’s no wonder that those people get frustrated.  They know and understand the reality of product development is inherently uncertain, and that success comes not from ignoring such uncertainty, but accepting it and responding to it when it appears.

Accepting Uncertainty Supports Creativity

Uncertainty is the fertile ground of creativity and freedom.
– Deepak Chopra

Companies often seem to forget that software engineers are mostly people who have spent years of their lives training and learning about ways to solve complex problems through the use of computerized systems.  They shouldn’t be presumed to be someone who just takes orders delivered via spec, checks off the boxes, and hands back software that meets the exact requirements asked of them (though, to be fair, I have met some developers who do prefer to work this way).  When we respect the fact that these people are highly intelligent, highly capable, and focused on solving problems, we can provide them with the proper groundwork to engage their creativity and to find new and innovative solutions to the problems that we pose.  The more tightly we constrain the area in which they have to work, the less likely they are to come up with new ideas that change the fundamentals of our products.  We want our teams to think for themselves, with the customer in mind.  When we pretend that they can’t, or when we exert authoritarian influence over them so that they won’t, we’re wasting their time and ours — and we shouldn’t be surprised when the outcome is evolutionary and never revolutionary.

Accepting Uncertainty Provides Breathing Room

I love deadlines. I love the whooshing sound they make as they go by.
– Douglas Adams

One of the most common complaints that I hear from development teams about “the business” centers around estimation and deadlines — in fact, it’s the primary source of the entire #noestimates movement, in my opinion.  They chafe at the use of early-stage estimates to set deadlines and delivery dates — and rightfully so, since these estimations are often performed without any hands-on work being done.  It’s a side-effect of the false sense of certainty that BUFR approaches generate — if the business is “certain” about what needs to be done, the direct corollary that’s assumed is that the development team must be equally certain about what needs to be done and how long it will take.  But anyone with actual experience will tell you hours of tales about deadlines that passed by, about delivery schedules that were constantly shifted later and later, and likely the fact that it’s the exception rather than the rule that such targets were actually hit.  Instead, if we’re being more agile in our cultural approach and more Agile in our practices to achieve our goals, then we’re constantly looking at and adjusting our scope as we get closer and closer to a “deadline” — or we’re making intelligent decisions based on actual facts about delaying those “deadlines” at the end of every iteration.  Rather than having a specific, pre-set list of things that “must” be done with only an abstract connection to reality, we can instead engage in conversations with our stakeholders about where we are, what’s the next most important thing, and when we think we’ll have something worthy of the customer.  It’s not a bill of goods, it’s an ongoing negotiation — which allows us to create high-quality solutions that aren’t bending or breaking under pressure of artificial and preset deadlines from people without actual data on the project.