Just reading “The Known, the Unknown, and the Unknowable in financial risk management” by Diebold et al.
Although the book deals with a different domain, that of financial markets, I find many of the messages of the book very applicable to systems- and software development, or more generally, to any collaborative, non-trivial effort where humans are key participants.
In particular, the message that in any development effort we need to acknowledge three different kinds of risks, “the known”, “the unknown” and “the unknowable”.
Despite the ongoing movement towards agility in modern software business, where we “willingly” embrace change and uncertainty, I still see a lot of traditional thinking in our business, in particular when looking outside the development teams, to corporate functions such as mgmt, sales, operations, finance, HR etc, where plans, predictions, forecasts and decisions are made based on a naive belief that a development project or a development organisation is fully deterministic and predictable, where most if not all possible events, risks and their probability distribution can be known, if we only have enough of detailed enough data.
Not least the current marketing buzz of the “next big thing”, “Big Data & Business Analytics”, can easily lead the innocent mind to believe that if we only had enough data with metrics and measurements on every conceivable aspect of our business and our operations, we would be able to monitor, plan, steer, forecast and predict our outcomes perfectly. Furthermore, with enough data, we’d be able to identify all risk, current and future, and thus mitigate that risk by taking appropriate action.
I doubt it…
It was not very long ago when many software development guru’s talked about “iterative, risk driven development”, i.e. a process where risk was used to define and drive iterations, the key idea being that those areas that exhibit most risk should be addressed first. Nothing wrong with that approach, except that the notion of “risk” demands that you have a priori knowlege of not just all the risky events that your project might encounter, but in addition to that, you must also know the exact probability distribution for each of those risks! I find it very unlikely for any non-trivial project to be 100% aware of all risky (future) events, and even more unlikely that it’s possible to know the probability distribution for all those events.
As I’ve described in previous posts, I see systems and software development projects as highly non- deterministic and non-predictable: they belong to the Complex System domain, with clear non-linear and dynamic characteristics, i.e. they exhibit a large degree of complexity and apparent randomness, most of which does not belong to the fairly easy to deal with “risk” category (“the known”), where events and their probability distributions are, or can be, known. Over and above the “risk”, there’s also the much more difficult “uncertainty” category in our business, i.e. the “unknown”, where we might have knowledge about the potentially risky events, but where we have no idea of the probabilities. And finally, in software development, there’s also the very unpleasant “the unknowable” events, i.e. the “Black Swans” (Taleb) that no one can foresee, and whose consequences are equally unknown ahead of time.
To successfully “steer” systems and software development projects, we’d better abandon the notion of predictability, determinism and “mild randomness” (Taleb, Mandelbrot) caused by the “known risks”, and acknowledge and deal with the “wild randomness” caused by the uncertainty inherent in “the unknowns” and the Black Swan’s or “the unknowable’s” inherent in much of our business.
True Agility, when done with the right mindset, fully acknowledging the complex system characteristics of software development and the existence of uncertainty, in all aspects, might prove to be a much better paradigm to steer these complex projects and organization than anything we’ve attempted before in our business. Therefore, it’s very refreshing to see Hendrik Esser of Ericsson to very clearly acknowledge the importance of being able to “live with uncertainty” in this recent interview on Ericsson’s recent agile transformation.