No this is not an obscure 60’s Spy/Detective series (cue John Barry theme music), by The Unknowables I mean the things you cannot possibly predict, the unknown unknowns.
Let’s start at the beginning.
It’s common practice on any software project to eliminate unknowns as soon as possible. It is ‘knowledge work’ after all and the more knowledge you gain about the specifics of your particular project the better armed you are going to be. Unknowns are classed as a risk because the effort to eliminate them is in itself unknown as is the potential impact it may have on your project.
As Donald Rumsfeld famously stated (and famously lampooned for):
“There are known knowns; there are things we know that we know.
There are known unknowns; that is to say, there are things that we now know we don’t know.
But there are also unknown unknowns – there are things we do not know we don’t know.”
Known unknowns should summarily be dealt with. That is to say, turn those suckers into known knowns. Decades of risk management practice should not be ignored.
Unknown unknowns are more interesting. By definition, at this point in time they are unknowable so make peace with that fact. This is not to say you cannot do anything about them. The idea of ‘contingency’ built into a schedule is instinctively or decisively added for this reason.
A mobile apps project I recently worked on suffered from the following unknowns uknowns, i.e. they were unknowable before they actually occurred:
- The company suddenly underwent a name change
- The power failed in the building and the generator that took over caught fire resulting in days of power outages and building evacuations
- Apples iTunes Connect site was hacked and Apple took it off line for several days at the time when multiple teams were supposed to be submitting apps to Apple for review
No one on the projects predicted these but they had an impact.
OK so what is one to do? Contingency is good. Acknowledge bad things will happen. Allow yourself wiggle room in multiple dimensions, i.e. time, cost, scope.
Agile projects in many ways set up an operating context for dealing with such eventualities in a more efficient and more effective manner. You can also say in a less painful manner. For example, if project stakeholders are not holding the team to a contractually fixed time, cost and scope, then adjusting for unknown unknowns becomes much more tolerable. Stakeholders should have their expectation managed to expect such scenarios to arise and to be flexible. No reasonable human being can expect a Scrum Master, developer or Product Owner to know all of the unknowns up front. Even the Secretary of Defence of the most powerful nation on Earth had to admit this!