Throughout reading the excellent book, Black Swan, by Nassim Nicolas Taleb, I was trying to think of scenarios and examples I that I've seen that I could apply to what Taleb was talking about. Although I don't really follow economics, I did find myself thinking about agile software development.
I don't want to go into what Black Swans are, other than to say they represent a highly improbable event, if you want to know more, pick up a copy of the book. Essentially, Taleb says that when a Black Swan occurs the affects can be disastrous because they are often ignored when calculating risks. Of course, many Black Swans are unknown unknowns, so how can you measure something like that? Well, you can't, but as the saying goes, "it's better to be broadly right then precisely wrong".
So, how does this apply to agile? Well, the way I've practiced it, it's about drilling out uncertainty by planning a prioritised work stack for a limited scope (generally 3 months). This minimises risk by only addressing immediate and near term issues, allowing a project to be flexible (think broadly right rather than precisely wrong). The daily stand ups, acceptance demos and retrospectives are all forums for identifying risk early in the hope of lowering the overall risk to a project delivery. Finally, and above all, agile and it's practices of test driven design, continuous integration and burn down charts display empirical evidence of delivery, rather than anecdotal.
In todays software world where it's acceptable to delivery functional, if not complete, applications into service, why wouldn't you want to work with a limited prioritised stack with empirical evidence to demonstrate readiness?
