I’m often asked what the key to being “agile” really is, and over the years I’ve managed to come up with a clear and concise answer: accepting uncertainty is the key to agility. It is perhaps the single most fundamental culture change that companies must go through when making a true transition to Agile development, and it’s often the biggest stumbling block that prevents them from fully becoming agile. You can see this in so many anti-patterns of Agile development: long-term, specific roadmaps; set dates and forced marches; iterations that are dictated, not created by and for the teams; and so many others. All of these behaviors stem from an organizational inability to accept that there are things that we don’t know about the work we’re trying to do, and that the best way to drive out that uncertainty is not by layering analysis and conjecture over it, but rather accepting it and moving forward, driving it out as we go along.
Accepting Uncertainty is Accepting Reality
First and foremost, being able to accept that there are things that we don’t yet know about any work that we’re starting is simply facing reality. It’s nearly impossible for any team of any composition to fully know the scope, scale, and breadth of work that is required to achieve any significant milestone in your product development. That’s the bad, old way of waterfall development — de-risk by over-analyzing, over-defining, and over-specifying everything, only to wind up with heavy change management processes dropped on top of that to make everyone’s lives a living hell. I know of zero long-term projects that didn’t wind up with changes in scope over time, regardless of how well-spec’d, well-thought out, well-understood that original scope might have been. There is, was, and always will be things that we don’t know about and cannot predict about any project that we’re starting work on. Truly being agile requires that we understand this, accept it, and don’t allow it to get in the way of us starting a project — because we know things will change as we learn.
Accepting Uncertainty Allows Us to Start Iterating Now
Practically, being able to accept uncertainty about our project, product, or feature allows us to start work and begin learning without delaying for lengthy analysis that is likely to be irrelevant within a few sprints regardless. If we do this, and we engage in spikes that deliver proofs of concept, or just start working on what we do know at the present time, then we can start delivering valuable product increments immediately. Time spent gathering more information is better spent as time actually building something, even if that something doesn’t wind up being the be-all, end-all solution that we want in the long run. Once we have learned something, we can incorporate that learning into our next iteration, and the next, and the next — constantly iterating to deliver additional product increments, while driving out the uncertainty that is present over time. We won’t figure out everything, but we will be able to shift some of those unknowns from the “unknown unknowns” bucket into the “known unknowns” bucket, and eventually discard them entirely as “known knowns”.
Accepting Uncertainty Lets Us Manage Expectations
Finally, while it might initially seem contradictory, adopting a culture that accepts uncertainty actually enables us as Product Managers to be more proactive in managing the expectations of our stakeholders. A lot of the miscommunication and misunderstanding that surrounds stakeholder expectations comes from the false sense of certainty and specificity that waterfall, big-upfront-requirements approaches bring with them. When we dispose of the pretense of understanding the entire scope and scale of a project at the outset, people are less likely to be surprised or disappointed when things change as we move forward — in fact, if we’re doing it right, they should be expecting it. We can then engage in the kinds of conversations that we need to as we learn more about the project — tradeoffs between scope and date, new directions that should be considered, and regular reviews of what is done with a lens toward “how quickly can we release this” rather than “what percent complete are we?” If the organization as a whole truly accepts uncertainty, then it becomes the Product Manager’s job not to shepherd everything toward a date — but rather to manage scope intelligently and engage with teams in a learning process, not just a checklist of deliverables pre-generated based on assumptions, presumptions, and a false sense of certainty.
